From 6bf2a79651e2aee2aab8e83facbd4fe051d94bfb Mon Sep 17 00:00:00 2001 From: Mirko Da Corte Date: Tue, 12 Nov 2024 13:27:27 +0100 Subject: [PATCH 01/17] swarm video hashes --- ...oduction-to-post-quantum-signature-schemes-for-ethereum.json | 2 +- ...-music-protocol-into-the-real-world-onboarding-millions.json | 2 +- .../devcon-7/bringing-ethereum-to-1b-telegram-users.json | 2 +- .../sessions/devcon-7/building-developer-communities-101.json | 2 +- ...s-the-real-world-understanding-the-cryptonative-economy.json | 2 +- ...crypto-twitter-is-wrong-this-is-how-rollups-really-work.json | 2 +- ...-practices-and-why-we-need-to-start-with-builders-first.json | 2 +- .../devcon-7/eip-7251-maximum-effective-balance-overview.json | 2 +- .../data/sessions/devcon-7/eip-7702-a-technical-deep-dive.json | 2 +- .../ens-war-stories-securing-web3-from-web2-based-attacks.json | 2 +- ...ntroduction-to-multilateral-trade-credit-set-off-in-mpc.json | 2 +- ...aci-why-do-we-need-private-voting-and-what-are-we-up-to.json | 2 +- devcon-api/data/sessions/devcon-7/modern-zkp-compilers.json | 2 +- .../devcon-7/mopro-make-client-side-proving-on-mobile-easy.json | 2 +- .../devcon-7/mpc-tooling-or-how-to-create-mpc-apps.json | 2 +- devcon-api/data/sessions/devcon-7/mpcstats.json | 2 +- .../data/sessions/devcon-7/privacy-preserving-groups.json | 2 +- ...reimagining-layer-0-new-worlds-and-ancient-philosophies.json | 2 +- .../devcon-7/scaling-community-lessons-from-building-base.json | 2 +- devcon-api/data/sessions/devcon-7/semaphore-v4.json | 2 +- ...ns-elephant-a-product-vision-towards-private-identities.json | 2 +- .../sessions/devcon-7/understanding-eip-7002-and-eip-6110.json | 2 +- .../devcon-7/why-vpns-are-scams-and-what-to-do-about-it.json | 2 +- 23 files changed, 23 insertions(+), 23 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/an-introduction-to-post-quantum-signature-schemes-for-ethereum.json b/devcon-api/data/sessions/devcon-7/an-introduction-to-post-quantum-signature-schemes-for-ethereum.json index 2b58be48..bda0bf67 100644 --- a/devcon-api/data/sessions/devcon-7/an-introduction-to-post-quantum-signature-schemes-for-ethereum.json +++ b/devcon-api/data/sessions/devcon-7/an-introduction-to-post-quantum-signature-schemes-for-ethereum.json @@ -23,7 +23,7 @@ ], "duration": 575, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "21ab9203390537d2ac46194c71f63c394cc6151c9464a574c67049bf8f07dcf3", "sources_youtubeId": "S3yf7c4GCbk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/bringing-an-open-music-protocol-into-the-real-world-onboarding-millions.json b/devcon-api/data/sessions/devcon-7/bringing-an-open-music-protocol-into-the-real-world-onboarding-millions.json index 6e7d4978..10ef8254 100644 --- a/devcon-api/data/sessions/devcon-7/bringing-an-open-music-protocol-into-the-real-world-onboarding-millions.json +++ b/devcon-api/data/sessions/devcon-7/bringing-an-open-music-protocol-into-the-real-world-onboarding-millions.json @@ -25,7 +25,7 @@ ], "duration": 441, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "ce2604d6133c8452dee58f52c72413f9bf8be020ed9eeb8ffbf5bf634749c74c", "sources_youtubeId": "G-OP4yxs5VU", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/bringing-ethereum-to-1b-telegram-users.json b/devcon-api/data/sessions/devcon-7/bringing-ethereum-to-1b-telegram-users.json index 37b5633a..02701e5e 100644 --- a/devcon-api/data/sessions/devcon-7/bringing-ethereum-to-1b-telegram-users.json +++ b/devcon-api/data/sessions/devcon-7/bringing-ethereum-to-1b-telegram-users.json @@ -25,7 +25,7 @@ ], "duration": 558, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "4260dbd123f3448c32e94796b2c75769a70901b3a5bf4ec8e0eba1a04e20f4d0", "sources_youtubeId": "ul1D6N8qVJU", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/building-developer-communities-101.json b/devcon-api/data/sessions/devcon-7/building-developer-communities-101.json index 93d94cfe..9b4fa4c7 100644 --- a/devcon-api/data/sessions/devcon-7/building-developer-communities-101.json +++ b/devcon-api/data/sessions/devcon-7/building-developer-communities-101.json @@ -23,7 +23,7 @@ ], "duration": 464, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "c40c5e3977516472e2a3c6acc41741648c8ab34684462e462f11d84b20326bea", "sources_youtubeId": "2og2d0Xxc3I", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/crypto-is-the-real-world-understanding-the-cryptonative-economy.json b/devcon-api/data/sessions/devcon-7/crypto-is-the-real-world-understanding-the-cryptonative-economy.json index 3689efed..32afdd5f 100644 --- a/devcon-api/data/sessions/devcon-7/crypto-is-the-real-world-understanding-the-cryptonative-economy.json +++ b/devcon-api/data/sessions/devcon-7/crypto-is-the-real-world-understanding-the-cryptonative-economy.json @@ -25,7 +25,7 @@ ], "duration": 991, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c", "sources_youtubeId": "Y0u6J1OmPXc", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/crypto-twitter-is-wrong-this-is-how-rollups-really-work.json b/devcon-api/data/sessions/devcon-7/crypto-twitter-is-wrong-this-is-how-rollups-really-work.json index ecd17e58..16b56a7d 100644 --- a/devcon-api/data/sessions/devcon-7/crypto-twitter-is-wrong-this-is-how-rollups-really-work.json +++ b/devcon-api/data/sessions/devcon-7/crypto-twitter-is-wrong-this-is-how-rollups-really-work.json @@ -23,7 +23,7 @@ ], "duration": 1311, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d", "sources_youtubeId": "c1IbglrscSU", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first.json b/devcon-api/data/sessions/devcon-7/ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first.json index 7e9f76a3..1aefd28f 100644 --- a/devcon-api/data/sessions/devcon-7/ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first.json +++ b/devcon-api/data/sessions/devcon-7/ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first.json @@ -27,7 +27,7 @@ ], "duration": 407, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896", "sources_youtubeId": "xqs8trszoOY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/eip-7251-maximum-effective-balance-overview.json b/devcon-api/data/sessions/devcon-7/eip-7251-maximum-effective-balance-overview.json index 2b6c9a3a..f5b2a823 100644 --- a/devcon-api/data/sessions/devcon-7/eip-7251-maximum-effective-balance-overview.json +++ b/devcon-api/data/sessions/devcon-7/eip-7251-maximum-effective-balance-overview.json @@ -21,7 +21,7 @@ ], "duration": 1218, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc", "sources_youtubeId": "EwW6dNi9VCY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/eip-7702-a-technical-deep-dive.json b/devcon-api/data/sessions/devcon-7/eip-7702-a-technical-deep-dive.json index e3887536..0461e4a5 100644 --- a/devcon-api/data/sessions/devcon-7/eip-7702-a-technical-deep-dive.json +++ b/devcon-api/data/sessions/devcon-7/eip-7702-a-technical-deep-dive.json @@ -21,7 +21,7 @@ ], "duration": 1299, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", "sources_youtubeId": "_k5fKlKBWV4", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/ens-war-stories-securing-web3-from-web2-based-attacks.json b/devcon-api/data/sessions/devcon-7/ens-war-stories-securing-web3-from-web2-based-attacks.json index 3c3a8a7b..24fd9888 100644 --- a/devcon-api/data/sessions/devcon-7/ens-war-stories-securing-web3-from-web2-based-attacks.json +++ b/devcon-api/data/sessions/devcon-7/ens-war-stories-securing-web3-from-web2-based-attacks.json @@ -26,7 +26,7 @@ ], "duration": 781, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "ddf9a9beb6a6cc606ece80ac2cfa5b7ea1dc15ed7e74f90748997b8a953b8574", "sources_youtubeId": "ht_Szqvtx8w", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/introduction-to-multilateral-trade-credit-set-off-in-mpc.json b/devcon-api/data/sessions/devcon-7/introduction-to-multilateral-trade-credit-set-off-in-mpc.json index 5d27b14e..3cc50e71 100644 --- a/devcon-api/data/sessions/devcon-7/introduction-to-multilateral-trade-credit-set-off-in-mpc.json +++ b/devcon-api/data/sessions/devcon-7/introduction-to-multilateral-trade-credit-set-off-in-mpc.json @@ -19,7 +19,7 @@ ], "duration": 680, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb", "sources_youtubeId": "OCEEe8azbR8", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/maci-why-do-we-need-private-voting-and-what-are-we-up-to.json b/devcon-api/data/sessions/devcon-7/maci-why-do-we-need-private-voting-and-what-are-we-up-to.json index 540bccb9..09b7c912 100644 --- a/devcon-api/data/sessions/devcon-7/maci-why-do-we-need-private-voting-and-what-are-we-up-to.json +++ b/devcon-api/data/sessions/devcon-7/maci-why-do-we-need-private-voting-and-what-are-we-up-to.json @@ -24,7 +24,7 @@ ], "duration": 606, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6", "sources_youtubeId": "18KFAia72Ww", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/modern-zkp-compilers.json b/devcon-api/data/sessions/devcon-7/modern-zkp-compilers.json index 88438050..c17793cc 100644 --- a/devcon-api/data/sessions/devcon-7/modern-zkp-compilers.json +++ b/devcon-api/data/sessions/devcon-7/modern-zkp-compilers.json @@ -23,7 +23,7 @@ ], "duration": 645, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c", "sources_youtubeId": "JX9YtcG_EHk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/mopro-make-client-side-proving-on-mobile-easy.json b/devcon-api/data/sessions/devcon-7/mopro-make-client-side-proving-on-mobile-easy.json index 4ade8b4e..c63057a7 100644 --- a/devcon-api/data/sessions/devcon-7/mopro-make-client-side-proving-on-mobile-easy.json +++ b/devcon-api/data/sessions/devcon-7/mopro-make-client-side-proving-on-mobile-easy.json @@ -24,7 +24,7 @@ ], "duration": 958, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649", "sources_youtubeId": "0ziKiYwhJHk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/mpc-tooling-or-how-to-create-mpc-apps.json b/devcon-api/data/sessions/devcon-7/mpc-tooling-or-how-to-create-mpc-apps.json index be11c5e7..9befc94a 100644 --- a/devcon-api/data/sessions/devcon-7/mpc-tooling-or-how-to-create-mpc-apps.json +++ b/devcon-api/data/sessions/devcon-7/mpc-tooling-or-how-to-create-mpc-apps.json @@ -23,7 +23,7 @@ ], "duration": 489, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa", "sources_youtubeId": "eKpcf1JMNak", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/mpcstats.json b/devcon-api/data/sessions/devcon-7/mpcstats.json index 38737ff9..08b2530c 100644 --- a/devcon-api/data/sessions/devcon-7/mpcstats.json +++ b/devcon-api/data/sessions/devcon-7/mpcstats.json @@ -30,7 +30,7 @@ ], "duration": 508, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51", "sources_youtubeId": "wCp7Zsjou7w", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/privacy-preserving-groups.json b/devcon-api/data/sessions/devcon-7/privacy-preserving-groups.json index 57ea0522..94471529 100644 --- a/devcon-api/data/sessions/devcon-7/privacy-preserving-groups.json +++ b/devcon-api/data/sessions/devcon-7/privacy-preserving-groups.json @@ -39,7 +39,7 @@ ], "duration": 464, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8", "sources_youtubeId": "dWQWoqJVfn8", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/reimagining-layer-0-new-worlds-and-ancient-philosophies.json b/devcon-api/data/sessions/devcon-7/reimagining-layer-0-new-worlds-and-ancient-philosophies.json index 704e63e7..b70b6dbf 100644 --- a/devcon-api/data/sessions/devcon-7/reimagining-layer-0-new-worlds-and-ancient-philosophies.json +++ b/devcon-api/data/sessions/devcon-7/reimagining-layer-0-new-worlds-and-ancient-philosophies.json @@ -27,7 +27,7 @@ ], "duration": 1568, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67", "sources_youtubeId": "rhDemdcnVVE", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/scaling-community-lessons-from-building-base.json b/devcon-api/data/sessions/devcon-7/scaling-community-lessons-from-building-base.json index 168db699..b52f19be 100644 --- a/devcon-api/data/sessions/devcon-7/scaling-community-lessons-from-building-base.json +++ b/devcon-api/data/sessions/devcon-7/scaling-community-lessons-from-building-base.json @@ -26,7 +26,7 @@ ], "duration": 574, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "4e8c46194a8800b5909aeb01cc6c0324728e82519f7c0ad031cb1149411d564e", "sources_youtubeId": "7T9YaSIAk2s", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/semaphore-v4.json b/devcon-api/data/sessions/devcon-7/semaphore-v4.json index d24e32b8..7d45e9c5 100644 --- a/devcon-api/data/sessions/devcon-7/semaphore-v4.json +++ b/devcon-api/data/sessions/devcon-7/semaphore-v4.json @@ -26,7 +26,7 @@ ], "duration": 1035, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691", "sources_youtubeId": "OErC2MyIKjY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-blind-mans-elephant-a-product-vision-towards-private-identities.json b/devcon-api/data/sessions/devcon-7/the-blind-mans-elephant-a-product-vision-towards-private-identities.json index e090a207..066124e3 100644 --- a/devcon-api/data/sessions/devcon-7/the-blind-mans-elephant-a-product-vision-towards-private-identities.json +++ b/devcon-api/data/sessions/devcon-7/the-blind-mans-elephant-a-product-vision-towards-private-identities.json @@ -26,7 +26,7 @@ ], "duration": 706, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9", "sources_youtubeId": "-BESF3MUM20", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/understanding-eip-7002-and-eip-6110.json b/devcon-api/data/sessions/devcon-7/understanding-eip-7002-and-eip-6110.json index 90ffa091..31f3b4a8 100644 --- a/devcon-api/data/sessions/devcon-7/understanding-eip-7002-and-eip-6110.json +++ b/devcon-api/data/sessions/devcon-7/understanding-eip-7002-and-eip-6110.json @@ -19,7 +19,7 @@ ], "duration": 1495, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34", "sources_youtubeId": "EyDChjFQEkQ", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/why-vpns-are-scams-and-what-to-do-about-it.json b/devcon-api/data/sessions/devcon-7/why-vpns-are-scams-and-what-to-do-about-it.json index 4ef62451..2b463fbf 100644 --- a/devcon-api/data/sessions/devcon-7/why-vpns-are-scams-and-what-to-do-about-it.json +++ b/devcon-api/data/sessions/devcon-7/why-vpns-are-scams-and-what-to-do-about-it.json @@ -23,7 +23,7 @@ ], "duration": 538, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6", "sources_youtubeId": "4Ir-fptXPr8", "sources_ipfsHash": "", "sources_livepeerId": "", From 9c09f931ce0e3efb872b2a9afeea548afc25021c Mon Sep 17 00:00:00 2001 From: Mirko Da Corte Date: Tue, 12 Nov 2024 20:36:31 +0100 Subject: [PATCH 02/17] add video swarm hashes --- ...-mouse-game-how-to-frontrun-a-transaction-in-the-future.json | 2 +- .../devcon-7/an-introduction-to-cryptography-new-and-old.json | 2 +- ...developing-and-maintaining-open-source-software-in-web3.json | 2 +- .../cultivating-the-understory-building-resilient-daos.json | 2 +- ...imization-techniques-of-the-onchain-and-offchain-worlds.json | 2 +- .../devcon-7/daos-unmasked-the-hard-truths-behind-the-hype.json | 2 +- ...ivacy-in-digital-identity-to-prevent-a-dystopian-crisis.json | 2 +- ...o-real-decentralization-in-a-world-of-centralized-power.json | 2 +- .../devcon-7/ethereum-execution-layer-specifications-eels.json | 2 +- .../devcon-7/evm-object-format-eof-history-and-motivation.json | 2 +- devcon-api/data/sessions/devcon-7/evolution-of-scams.json | 2 +- .../keynote-programmable-cryptography-and-ethereum.json | 2 +- devcon-api/data/sessions/devcon-7/keynote-title-redacted.json | 2 +- .../sessions/devcon-7/lighthouse-introduction-to-siren.json | 2 +- .../opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt.json | 2 +- ...research-what-you-dont-know-can-hurt-you-and-your-users.json | 2 +- ...rogrammable-cryptography-and-the-future-of-the-internet.json | 2 +- .../data/sessions/devcon-7/public-private-hybrid-rollups.json | 2 +- .../data/sessions/devcon-7/rethinking-user-risks-at-l2beat.json | 2 +- .../scaling-ethereum-with-das-an-iterative-approach.json | 2 +- ...rity-through-obscurity-using-microdots-to-store-secrets.json | 2 +- devcon-api/data/sessions/devcon-7/stark-proofs-eli5.json | 2 +- devcon-api/data/sessions/devcon-7/tales-from-interop.json | 2 +- ...-10-most-common-vulnerabilities-found-in-audit-contests.json | 2 +- .../data/sessions/devcon-7/the-combination-of-zkp-mpc-fhe.json | 2 +- ...he-next-era-sequencing-and-its-real-impact-on-app-users.json | 2 +- .../the-next-generation-of-decentralized-governance.json | 2 +- .../the-state-of-web3-support-today-what-just-happened.json | 2 +- .../sessions/devcon-7/the-trustless-trade-supply-chain.json | 2 +- .../transaction-simulation-the-good-the-bad-and-the-ugly.json | 2 +- .../sessions/devcon-7/whats-going-into-the-pectra-upgrade.json | 2 +- .../devcon-7/zkmpc-bring-public-auditability-into-mpc.json | 2 +- 32 files changed, 32 insertions(+), 32 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/a-cat-and-mouse-game-how-to-frontrun-a-transaction-in-the-future.json b/devcon-api/data/sessions/devcon-7/a-cat-and-mouse-game-how-to-frontrun-a-transaction-in-the-future.json index 95f14bca..3c537f4b 100644 --- a/devcon-api/data/sessions/devcon-7/a-cat-and-mouse-game-how-to-frontrun-a-transaction-in-the-future.json +++ b/devcon-api/data/sessions/devcon-7/a-cat-and-mouse-game-how-to-frontrun-a-transaction-in-the-future.json @@ -25,7 +25,7 @@ ], "duration": 356, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a3b09fc1d984db767d8af93657fd54b64f8af7c9391ada66823ed99d63801ffb", "sources_youtubeId": "PtYZgh6bYfE", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/an-introduction-to-cryptography-new-and-old.json b/devcon-api/data/sessions/devcon-7/an-introduction-to-cryptography-new-and-old.json index a23649d7..8953bd76 100644 --- a/devcon-api/data/sessions/devcon-7/an-introduction-to-cryptography-new-and-old.json +++ b/devcon-api/data/sessions/devcon-7/an-introduction-to-cryptography-new-and-old.json @@ -25,7 +25,7 @@ ], "duration": 1465, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "16a3771bca4b5ce1a6ac65bcc81327d002a7cb59b050322799fee53af537ac03", "sources_youtubeId": "E6u3uQGP9J4", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/challenges-developing-and-maintaining-open-source-software-in-web3.json b/devcon-api/data/sessions/devcon-7/challenges-developing-and-maintaining-open-source-software-in-web3.json index ed613ce6..6ed8c6bc 100644 --- a/devcon-api/data/sessions/devcon-7/challenges-developing-and-maintaining-open-source-software-in-web3.json +++ b/devcon-api/data/sessions/devcon-7/challenges-developing-and-maintaining-open-source-software-in-web3.json @@ -25,7 +25,7 @@ ], "duration": 545, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "25e6ed887207dbca41799d009fc12cdef9f1b8e73205686de952a3102690d3fe", "sources_youtubeId": "U93wI1oLKCA", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/cultivating-the-understory-building-resilient-daos.json b/devcon-api/data/sessions/devcon-7/cultivating-the-understory-building-resilient-daos.json index 5b14114f..b0139c47 100644 --- a/devcon-api/data/sessions/devcon-7/cultivating-the-understory-building-resilient-daos.json +++ b/devcon-api/data/sessions/devcon-7/cultivating-the-understory-building-resilient-daos.json @@ -24,7 +24,7 @@ ], "duration": 1569, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d", "sources_youtubeId": "274Uyrxv6uI", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds.json b/devcon-api/data/sessions/devcon-7/daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds.json index 48072a64..a532ae66 100644 --- a/devcon-api/data/sessions/devcon-7/daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds.json +++ b/devcon-api/data/sessions/devcon-7/daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds.json @@ -24,7 +24,7 @@ ], "duration": 1641, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012", "sources_youtubeId": "2pYy07uUG4c", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/daos-unmasked-the-hard-truths-behind-the-hype.json b/devcon-api/data/sessions/devcon-7/daos-unmasked-the-hard-truths-behind-the-hype.json index d1ce687e..a46e361c 100644 --- a/devcon-api/data/sessions/devcon-7/daos-unmasked-the-hard-truths-behind-the-hype.json +++ b/devcon-api/data/sessions/devcon-7/daos-unmasked-the-hard-truths-behind-the-hype.json @@ -24,7 +24,7 @@ ], "duration": 1670, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c", "sources_youtubeId": "pdlMrmUxpSg", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis.json b/devcon-api/data/sessions/devcon-7/ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis.json index a102f4a3..2648c279 100644 --- a/devcon-api/data/sessions/devcon-7/ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis.json +++ b/devcon-api/data/sessions/devcon-7/ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis.json @@ -25,7 +25,7 @@ ], "duration": 1426, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "27893580368e8396780c9f103b3d94703c4ab1700db60ed5816b3334de7aff27", "sources_youtubeId": "6EJBsHydyVU", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json b/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json index 46b49fe1..37fb8417 100644 --- a/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json +++ b/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json @@ -25,7 +25,7 @@ ], "duration": 1502, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11", "sources_youtubeId": "kSrjley2POk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/ethereum-execution-layer-specifications-eels.json b/devcon-api/data/sessions/devcon-7/ethereum-execution-layer-specifications-eels.json index ecab2d07..ccc2959c 100644 --- a/devcon-api/data/sessions/devcon-7/ethereum-execution-layer-specifications-eels.json +++ b/devcon-api/data/sessions/devcon-7/ethereum-execution-layer-specifications-eels.json @@ -19,7 +19,7 @@ ], "duration": 1253, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802", "sources_youtubeId": "WEvCFg0Z1D4", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/evm-object-format-eof-history-and-motivation.json b/devcon-api/data/sessions/devcon-7/evm-object-format-eof-history-and-motivation.json index 7ff281a4..ef219e6c 100644 --- a/devcon-api/data/sessions/devcon-7/evm-object-format-eof-history-and-motivation.json +++ b/devcon-api/data/sessions/devcon-7/evm-object-format-eof-history-and-motivation.json @@ -22,7 +22,7 @@ ], "duration": 1503, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496", "sources_youtubeId": "X2mlptWzphc", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/evolution-of-scams.json b/devcon-api/data/sessions/devcon-7/evolution-of-scams.json index b8ee9f2e..f4d6fdea 100644 --- a/devcon-api/data/sessions/devcon-7/evolution-of-scams.json +++ b/devcon-api/data/sessions/devcon-7/evolution-of-scams.json @@ -21,7 +21,7 @@ ], "duration": 558, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537", "sources_youtubeId": "SgkEwSDkBnI", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/keynote-programmable-cryptography-and-ethereum.json b/devcon-api/data/sessions/devcon-7/keynote-programmable-cryptography-and-ethereum.json index fe00f615..8cfafbc1 100644 --- a/devcon-api/data/sessions/devcon-7/keynote-programmable-cryptography-and-ethereum.json +++ b/devcon-api/data/sessions/devcon-7/keynote-programmable-cryptography-and-ethereum.json @@ -19,7 +19,7 @@ ], "duration": 1517, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9", "sources_youtubeId": "UWPg_AmWtlw", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json b/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json index 3170f88e..3f572e88 100644 --- a/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json +++ b/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json @@ -24,7 +24,7 @@ ], "duration": 1553, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e", "sources_youtubeId": "Gjuenkv1zrw", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/lighthouse-introduction-to-siren.json b/devcon-api/data/sessions/devcon-7/lighthouse-introduction-to-siren.json index 6b66e641..52467a5d 100644 --- a/devcon-api/data/sessions/devcon-7/lighthouse-introduction-to-siren.json +++ b/devcon-api/data/sessions/devcon-7/lighthouse-introduction-to-siren.json @@ -24,7 +24,7 @@ ], "duration": 388, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4", "sources_youtubeId": "RhlKmJqk0go", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt.json b/devcon-api/data/sessions/devcon-7/opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt.json index ea9cb160..5330a5bf 100644 --- a/devcon-api/data/sessions/devcon-7/opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt.json +++ b/devcon-api/data/sessions/devcon-7/opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt.json @@ -29,7 +29,7 @@ ], "duration": 542, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c", "sources_youtubeId": "nM2BBNlIRe4", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users.json b/devcon-api/data/sessions/devcon-7/postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users.json index 9fa180c5..9a015c17 100644 --- a/devcon-api/data/sessions/devcon-7/postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users.json +++ b/devcon-api/data/sessions/devcon-7/postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users.json @@ -22,7 +22,7 @@ ], "duration": 434, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107", "sources_youtubeId": "NKGOZ154rPM", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json index f9b202b7..dbee401e 100644 --- a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json +++ b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json @@ -15,7 +15,7 @@ ], "duration": 3349, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c", "sources_youtubeId": "PSs8d_ZzFCk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/public-private-hybrid-rollups.json b/devcon-api/data/sessions/devcon-7/public-private-hybrid-rollups.json index 0e92a241..c03b56ab 100644 --- a/devcon-api/data/sessions/devcon-7/public-private-hybrid-rollups.json +++ b/devcon-api/data/sessions/devcon-7/public-private-hybrid-rollups.json @@ -25,7 +25,7 @@ ], "duration": 1396, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e", "sources_youtubeId": "0mDlVkzde_M", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/rethinking-user-risks-at-l2beat.json b/devcon-api/data/sessions/devcon-7/rethinking-user-risks-at-l2beat.json index 37dc19a1..c29e7cdb 100644 --- a/devcon-api/data/sessions/devcon-7/rethinking-user-risks-at-l2beat.json +++ b/devcon-api/data/sessions/devcon-7/rethinking-user-risks-at-l2beat.json @@ -24,7 +24,7 @@ ], "duration": 523, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9", "sources_youtubeId": "CM6e_wwieeo", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/scaling-ethereum-with-das-an-iterative-approach.json b/devcon-api/data/sessions/devcon-7/scaling-ethereum-with-das-an-iterative-approach.json index 7ed7337c..e41b3c4a 100644 --- a/devcon-api/data/sessions/devcon-7/scaling-ethereum-with-das-an-iterative-approach.json +++ b/devcon-api/data/sessions/devcon-7/scaling-ethereum-with-das-an-iterative-approach.json @@ -20,7 +20,7 @@ ], "duration": 1522, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "567a45d310dc81275e061b69797f55ce5386ac2d95acdaf5d71076c274539d71", "sources_youtubeId": "toR2UKzE_zA", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/security-through-obscurity-using-microdots-to-store-secrets.json b/devcon-api/data/sessions/devcon-7/security-through-obscurity-using-microdots-to-store-secrets.json index fc269f63..2a9d2565 100644 --- a/devcon-api/data/sessions/devcon-7/security-through-obscurity-using-microdots-to-store-secrets.json +++ b/devcon-api/data/sessions/devcon-7/security-through-obscurity-using-microdots-to-store-secrets.json @@ -26,7 +26,7 @@ ], "duration": 579, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52", "sources_youtubeId": "3mXa1oeHzzA", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/stark-proofs-eli5.json b/devcon-api/data/sessions/devcon-7/stark-proofs-eli5.json index d258835f..8db4e078 100644 --- a/devcon-api/data/sessions/devcon-7/stark-proofs-eli5.json +++ b/devcon-api/data/sessions/devcon-7/stark-proofs-eli5.json @@ -23,7 +23,7 @@ ], "duration": 496, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161", "sources_youtubeId": "eHPp8mFCS6E", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/tales-from-interop.json b/devcon-api/data/sessions/devcon-7/tales-from-interop.json index 6e8a2b88..f4990466 100644 --- a/devcon-api/data/sessions/devcon-7/tales-from-interop.json +++ b/devcon-api/data/sessions/devcon-7/tales-from-interop.json @@ -23,7 +23,7 @@ ], "duration": 1433, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d", "sources_youtubeId": "NHsi-lyOEUA", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-10-most-common-vulnerabilities-found-in-audit-contests.json b/devcon-api/data/sessions/devcon-7/the-10-most-common-vulnerabilities-found-in-audit-contests.json index 761eab39..bf06e9f6 100644 --- a/devcon-api/data/sessions/devcon-7/the-10-most-common-vulnerabilities-found-in-audit-contests.json +++ b/devcon-api/data/sessions/devcon-7/the-10-most-common-vulnerabilities-found-in-audit-contests.json @@ -24,7 +24,7 @@ ], "duration": 595, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0", "sources_youtubeId": "MT7mYhwgksI", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-combination-of-zkp-mpc-fhe.json b/devcon-api/data/sessions/devcon-7/the-combination-of-zkp-mpc-fhe.json index a59da729..6ad1fe5e 100644 --- a/devcon-api/data/sessions/devcon-7/the-combination-of-zkp-mpc-fhe.json +++ b/devcon-api/data/sessions/devcon-7/the-combination-of-zkp-mpc-fhe.json @@ -21,7 +21,7 @@ ], "duration": 521, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18", "sources_youtubeId": "Tq7CVqDE_P4", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-next-era-sequencing-and-its-real-impact-on-app-users.json b/devcon-api/data/sessions/devcon-7/the-next-era-sequencing-and-its-real-impact-on-app-users.json index 4b04d803..b5b773c0 100644 --- a/devcon-api/data/sessions/devcon-7/the-next-era-sequencing-and-its-real-impact-on-app-users.json +++ b/devcon-api/data/sessions/devcon-7/the-next-era-sequencing-and-its-real-impact-on-app-users.json @@ -23,7 +23,7 @@ ], "duration": 975, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d", "sources_youtubeId": "-S2rlhSUHZY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-next-generation-of-decentralized-governance.json b/devcon-api/data/sessions/devcon-7/the-next-generation-of-decentralized-governance.json index ba1d5b96..93b5c075 100644 --- a/devcon-api/data/sessions/devcon-7/the-next-generation-of-decentralized-governance.json +++ b/devcon-api/data/sessions/devcon-7/the-next-generation-of-decentralized-governance.json @@ -16,7 +16,7 @@ ], "duration": 1629, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603", "sources_youtubeId": "VhkP2OIwIFY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-state-of-web3-support-today-what-just-happened.json b/devcon-api/data/sessions/devcon-7/the-state-of-web3-support-today-what-just-happened.json index 3eadef59..65454d9c 100644 --- a/devcon-api/data/sessions/devcon-7/the-state-of-web3-support-today-what-just-happened.json +++ b/devcon-api/data/sessions/devcon-7/the-state-of-web3-support-today-what-just-happened.json @@ -21,7 +21,7 @@ ], "duration": 304, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4", "sources_youtubeId": "sur3bRJQw-U", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/the-trustless-trade-supply-chain.json b/devcon-api/data/sessions/devcon-7/the-trustless-trade-supply-chain.json index 7fc2799d..a0d8df0f 100644 --- a/devcon-api/data/sessions/devcon-7/the-trustless-trade-supply-chain.json +++ b/devcon-api/data/sessions/devcon-7/the-trustless-trade-supply-chain.json @@ -25,7 +25,7 @@ ], "duration": 460, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a", "sources_youtubeId": "9EPCog8GiiQ", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/transaction-simulation-the-good-the-bad-and-the-ugly.json b/devcon-api/data/sessions/devcon-7/transaction-simulation-the-good-the-bad-and-the-ugly.json index 327414be..d5b1d88b 100644 --- a/devcon-api/data/sessions/devcon-7/transaction-simulation-the-good-the-bad-and-the-ugly.json +++ b/devcon-api/data/sessions/devcon-7/transaction-simulation-the-good-the-bad-and-the-ugly.json @@ -23,7 +23,7 @@ ], "duration": 458, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f", "sources_youtubeId": "6-ygj7_IqEg", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/whats-going-into-the-pectra-upgrade.json b/devcon-api/data/sessions/devcon-7/whats-going-into-the-pectra-upgrade.json index 84ab336f..13c18575 100644 --- a/devcon-api/data/sessions/devcon-7/whats-going-into-the-pectra-upgrade.json +++ b/devcon-api/data/sessions/devcon-7/whats-going-into-the-pectra-upgrade.json @@ -20,7 +20,7 @@ ], "duration": 1515, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f", "sources_youtubeId": "ufIDBCgdGwY", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/zkmpc-bring-public-auditability-into-mpc.json b/devcon-api/data/sessions/devcon-7/zkmpc-bring-public-auditability-into-mpc.json index 15c0794c..6400dd23 100644 --- a/devcon-api/data/sessions/devcon-7/zkmpc-bring-public-auditability-into-mpc.json +++ b/devcon-api/data/sessions/devcon-7/zkmpc-bring-public-auditability-into-mpc.json @@ -23,7 +23,7 @@ ], "duration": 1399, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188", "sources_youtubeId": "aWQ8zzi1EAQ", "sources_ipfsHash": "", "sources_livepeerId": "", From f5eb91771fcc83f189f0878ac3208cfac219afe2 Mon Sep 17 00:00:00 2001 From: Mirko Da Corte Date: Wed, 13 Nov 2024 01:02:26 +0100 Subject: [PATCH 03/17] add video swarm hashes --- .../data/sessions/devcon-7/common-knowledge-machines.json | 2 +- .../sessions/devcon-7/dark-daos-and-private-coordination.json | 2 +- .../elliptic-curves-and-snarks-past-present-and-future.json | 2 +- devcon-api/data/sessions/devcon-7/ethereum-in-30-minutes.json | 1 + .../farcaster-frames-building-embeddable-ethereum-apps.json | 2 +- ...-nihilism-vs-foss-culture-the-battle-for-ethereums-soul.json | 2 +- ...ality-the-triumph-of-blockchain-in-vaccine-distribution.json | 2 +- .../keynote-infinite-diversity-in-infinite-combinations.json | 1 + .../mycofi-mycelial-design-patterns-for-web3-and-beyond.json | 2 +- .../devcon-7/open-challenges-in-mini-apps-and-frames.json | 2 +- devcon-api/data/sessions/devcon-7/opening-ceremony.json | 1 + .../devcon-7/optimism-retro-funding-so-far-so-good-so-what.json | 2 +- ...-interactions-transforming-user-experience-with-intents.json | 2 +- .../devcon-7/redefining-boundaries-in-the-infinite-garden.json | 1 + ...argames-to-prepare-protocol-teams-for-incident-response.json | 2 +- devcon-api/data/sessions/devcon-7/this-year-in-ethereum.json | 1 + 16 files changed, 16 insertions(+), 11 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json b/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json index a0a0b593..5e8fbf6c 100644 --- a/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json +++ b/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json @@ -22,7 +22,7 @@ ], "duration": 1057, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "2fadd824928c32a979645300678ee71dea6d46f238ba5f1acf48e3791e8e8005", "sources_youtubeId": "6VJYBNZioHg", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/dark-daos-and-private-coordination.json b/devcon-api/data/sessions/devcon-7/dark-daos-and-private-coordination.json index 8ed59622..39cc86e2 100644 --- a/devcon-api/data/sessions/devcon-7/dark-daos-and-private-coordination.json +++ b/devcon-api/data/sessions/devcon-7/dark-daos-and-private-coordination.json @@ -25,7 +25,7 @@ ], "duration": 1515, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e", "sources_youtubeId": "iU-2dwVVagk", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/elliptic-curves-and-snarks-past-present-and-future.json b/devcon-api/data/sessions/devcon-7/elliptic-curves-and-snarks-past-present-and-future.json index fec2c002..108a5fdf 100644 --- a/devcon-api/data/sessions/devcon-7/elliptic-curves-and-snarks-past-present-and-future.json +++ b/devcon-api/data/sessions/devcon-7/elliptic-curves-and-snarks-past-present-and-future.json @@ -25,7 +25,7 @@ ], "duration": 1518, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "d418d4f93106c8a1c844d7ddadd6ef00204c7d15d551d1e3a9732f82c007bf46", "sources_youtubeId": "Bey043R_52k", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/ethereum-in-30-minutes.json b/devcon-api/data/sessions/devcon-7/ethereum-in-30-minutes.json index 13fcd6b6..efecff97 100644 --- a/devcon-api/data/sessions/devcon-7/ethereum-in-30-minutes.json +++ b/devcon-api/data/sessions/devcon-7/ethereum-in-30-minutes.json @@ -20,5 +20,6 @@ "slot_end": 1731385800000, "slot_roomId": "main-stage", "sources_youtubeId": "ei3tDRMjw6k", + "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9", "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/farcaster-frames-building-embeddable-ethereum-apps.json b/devcon-api/data/sessions/devcon-7/farcaster-frames-building-embeddable-ethereum-apps.json index cf1adb7f..f4a86921 100644 --- a/devcon-api/data/sessions/devcon-7/farcaster-frames-building-embeddable-ethereum-apps.json +++ b/devcon-api/data/sessions/devcon-7/farcaster-frames-building-embeddable-ethereum-apps.json @@ -21,7 +21,7 @@ ], "duration": 5086, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316", "sources_youtubeId": "Tb1Pq3CvFh8", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul.json b/devcon-api/data/sessions/devcon-7/financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul.json index 7f889160..8b2eeea9 100644 --- a/devcon-api/data/sessions/devcon-7/financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul.json +++ b/devcon-api/data/sessions/devcon-7/financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul.json @@ -23,7 +23,7 @@ ], "duration": 1584, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc", "sources_youtubeId": "sNPxhnznfEA", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution.json b/devcon-api/data/sessions/devcon-7/from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution.json index dc13de9e..54ff004e 100644 --- a/devcon-api/data/sessions/devcon-7/from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution.json +++ b/devcon-api/data/sessions/devcon-7/from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution.json @@ -25,7 +25,7 @@ ], "duration": 974, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384", "sources_youtubeId": "0dSz0CN6bI8", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/keynote-infinite-diversity-in-infinite-combinations.json b/devcon-api/data/sessions/devcon-7/keynote-infinite-diversity-in-infinite-combinations.json index 6c69cbd8..2c1117a5 100644 --- a/devcon-api/data/sessions/devcon-7/keynote-infinite-diversity-in-infinite-combinations.json +++ b/devcon-api/data/sessions/devcon-7/keynote-infinite-diversity-in-infinite-combinations.json @@ -26,5 +26,6 @@ "slot_end": 1731391200000, "slot_roomId": "main-stage", "sources_youtubeId": "n3R4ze2hesk", + "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae", "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/mycofi-mycelial-design-patterns-for-web3-and-beyond.json b/devcon-api/data/sessions/devcon-7/mycofi-mycelial-design-patterns-for-web3-and-beyond.json index 39382aec..b906b6d6 100644 --- a/devcon-api/data/sessions/devcon-7/mycofi-mycelial-design-patterns-for-web3-and-beyond.json +++ b/devcon-api/data/sessions/devcon-7/mycofi-mycelial-design-patterns-for-web3-and-beyond.json @@ -32,7 +32,7 @@ ], "duration": 544, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07", "sources_youtubeId": "0A4jXL5eBaI", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/open-challenges-in-mini-apps-and-frames.json b/devcon-api/data/sessions/devcon-7/open-challenges-in-mini-apps-and-frames.json index a9d125f7..7c12495d 100644 --- a/devcon-api/data/sessions/devcon-7/open-challenges-in-mini-apps-and-frames.json +++ b/devcon-api/data/sessions/devcon-7/open-challenges-in-mini-apps-and-frames.json @@ -21,7 +21,7 @@ ], "duration": 480, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe", "sources_youtubeId": "xoMfU9Gk0xc", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/opening-ceremony.json b/devcon-api/data/sessions/devcon-7/opening-ceremony.json index 8308646c..ad498c86 100644 --- a/devcon-api/data/sessions/devcon-7/opening-ceremony.json +++ b/devcon-api/data/sessions/devcon-7/opening-ceremony.json @@ -20,5 +20,6 @@ "slot_end": 1731381300000, "slot_roomId": "main-stage", "sources_youtubeId": "dMLeSMcBskU", + "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab", "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/optimism-retro-funding-so-far-so-good-so-what.json b/devcon-api/data/sessions/devcon-7/optimism-retro-funding-so-far-so-good-so-what.json index 90183a04..19e4cd72 100644 --- a/devcon-api/data/sessions/devcon-7/optimism-retro-funding-so-far-so-good-so-what.json +++ b/devcon-api/data/sessions/devcon-7/optimism-retro-funding-so-far-so-good-so-what.json @@ -25,7 +25,7 @@ ], "duration": 1542, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74", "sources_youtubeId": "MmjAhdEbnV0", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json b/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json index 825cde45..9770fdef 100644 --- a/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json +++ b/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json @@ -21,7 +21,7 @@ ], "duration": 2896, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94", "sources_youtubeId": "9OANe6U9UL0", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/redefining-boundaries-in-the-infinite-garden.json b/devcon-api/data/sessions/devcon-7/redefining-boundaries-in-the-infinite-garden.json index 1bdc5814..2277f244 100644 --- a/devcon-api/data/sessions/devcon-7/redefining-boundaries-in-the-infinite-garden.json +++ b/devcon-api/data/sessions/devcon-7/redefining-boundaries-in-the-infinite-garden.json @@ -20,5 +20,6 @@ "slot_end": 1731384000000, "slot_roomId": "main-stage", "sources_youtubeId": "SE15rsPVHz0", + "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0", "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/running-wargames-to-prepare-protocol-teams-for-incident-response.json b/devcon-api/data/sessions/devcon-7/running-wargames-to-prepare-protocol-teams-for-incident-response.json index 0a1d7f0a..f0f06939 100644 --- a/devcon-api/data/sessions/devcon-7/running-wargames-to-prepare-protocol-teams-for-incident-response.json +++ b/devcon-api/data/sessions/devcon-7/running-wargames-to-prepare-protocol-teams-for-incident-response.json @@ -23,7 +23,7 @@ ], "duration": 1350, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "702aabf1c42143159cad1c657c1247f880937f9ed6f493fa9a9bdf4323e70723", "sources_youtubeId": "PLEJj9_1a7A", "sources_ipfsHash": "", "sources_livepeerId": "", diff --git a/devcon-api/data/sessions/devcon-7/this-year-in-ethereum.json b/devcon-api/data/sessions/devcon-7/this-year-in-ethereum.json index fe46a180..cba38fbb 100644 --- a/devcon-api/data/sessions/devcon-7/this-year-in-ethereum.json +++ b/devcon-api/data/sessions/devcon-7/this-year-in-ethereum.json @@ -20,5 +20,6 @@ "slot_end": 1731382800000, "slot_roomId": "main-stage", "sources_youtubeId": "YyK8i2-0aPk", + "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a", "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY" } \ No newline at end of file From 87c7a162c5c682233a33946725f360d5968f6bb6 Mon Sep 17 00:00:00 2001 From: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 02:16:34 +0000 Subject: [PATCH 04/17] [action] Pretalx Sync --- devcon-api/data/events/devcon-7.json | 2 +- ...c-bindings-for-constantine-verkle-ipa.json | 27 +++ .../devcon-7/c-implementation-of-libp2p.json | 4 +- ...enshrined-proposer-builder-separation.json | 4 +- ...-using-digital-matter-and-smart-items.json | 4 +- .../light-client-support-in-prysm.json | 4 +- ...-transition-journey-from-warp-to-axum.json | 4 +- .../liveops-for-autonomous-worlds.json | 4 +- .../devcon-7/mud-past-present-and-future.json | 28 +++ ...sforming-user-experience-with-intents.json | 2 +- .../devcon-7/the-age-of-aggregation.json | 3 +- .../tracing-integration-in-lighthouse.json | 4 +- devcon-api/data/speakers/marc-boiron.json | 8 + devcon-api/data/speakers/olivia-smith.json | 2 +- devcon-api/data/speakers/rachel.json | 4 +- devcon-api/data/speakers/vijay-mohan.json | 2 +- devcon-api/data/speakers/vivian-chen.json | 2 +- devcon-api/data/vectors/devcon-7.json | 182 ++++++++++++------ devcon-api/data/vectors/dictionary.json | 2 +- 19 files changed, 205 insertions(+), 87 deletions(-) create mode 100644 devcon-api/data/sessions/devcon-7/c-bindings-for-constantine-verkle-ipa.json create mode 100644 devcon-api/data/sessions/devcon-7/mud-past-present-and-future.json create mode 100644 devcon-api/data/speakers/marc-boiron.json diff --git a/devcon-api/data/events/devcon-7.json b/devcon-api/data/events/devcon-7.json index 38efbb22..cff9bcb6 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": "1731415367249" + "version": "1731463427614" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/c-bindings-for-constantine-verkle-ipa.json b/devcon-api/data/sessions/devcon-7/c-bindings-for-constantine-verkle-ipa.json new file mode 100644 index 00000000..0cbe3cb6 --- /dev/null +++ b/devcon-api/data/sessions/devcon-7/c-bindings-for-constantine-verkle-ipa.json @@ -0,0 +1,27 @@ +{ + "id": "c-bindings-for-constantine-verkle-ipa", + "sourceId": "TDQFPX", + "title": "C bindings for Constantine verkle-ipa", + "description": "The session is part of final presentation of Ethereum Protocol Fellowship. In this talk I would be talking about the verkle-ipa provided by Constantine and exporting those to be made available for integration by clients for the verkle integration of ethereum roadmap.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Cryptography", + "Ethereum Roadmap", + "Verkle trees" + ], + "language": "en", + "speakers": [ + "richa" + ], + "eventId": "devcon-7", + "slot_start": 1731473100000, + "slot_end": 1731474000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/10DqlfeLWBhwxvz53O8852FsvukCw9hOvBC9rvKdKNM8" +} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/c-implementation-of-libp2p.json b/devcon-api/data/sessions/devcon-7/c-implementation-of-libp2p.json index 8df8d6bd..aac08d34 100644 --- a/devcon-api/data/sessions/devcon-7/c-implementation-of-libp2p.json +++ b/devcon-api/data/sessions/devcon-7/c-implementation-of-libp2p.json @@ -25,8 +25,8 @@ "kira" ], "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731476700000, + "slot_start": 1731476700000, + "slot_end": 1731477600000, "slot_roomId": "breakout-1", "resources_presentation": "https://docs.google.com/presentation/d/114N7ZFoxay5HlB8T-LpY8iCOTKX70658i91W43eXDpc" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/eip-7732-enshrined-proposer-builder-separation.json b/devcon-api/data/sessions/devcon-7/eip-7732-enshrined-proposer-builder-separation.json index c5df68cb..17e7d211 100644 --- a/devcon-api/data/sessions/devcon-7/eip-7732-enshrined-proposer-builder-separation.json +++ b/devcon-api/data/sessions/devcon-7/eip-7732-enshrined-proposer-builder-separation.json @@ -25,8 +25,8 @@ "caleb" ], "eventId": "devcon-7", - "slot_start": 1731476700000, - "slot_end": 1731477600000, + "slot_start": 1731477600000, + "slot_end": 1731478500000, "slot_roomId": "breakout-1", "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/growing-the-biomes-gdp-using-digital-matter-and-smart-items.json b/devcon-api/data/sessions/devcon-7/growing-the-biomes-gdp-using-digital-matter-and-smart-items.json index 63875388..9f612b49 100644 --- a/devcon-api/data/sessions/devcon-7/growing-the-biomes-gdp-using-digital-matter-and-smart-items.json +++ b/devcon-api/data/sessions/devcon-7/growing-the-biomes-gdp-using-digital-matter-and-smart-items.json @@ -22,8 +22,8 @@ "dhvani-patel" ], "eventId": "devcon-7", - "slot_start": 1731579300000, - "slot_end": 1731580800000, + "slot_start": 1731567000000, + "slot_end": 1731568500000, "slot_roomId": "classroom-a", "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/light-client-support-in-prysm.json b/devcon-api/data/sessions/devcon-7/light-client-support-in-prysm.json index e606aba3..c4673d77 100644 --- a/devcon-api/data/sessions/devcon-7/light-client-support-in-prysm.json +++ b/devcon-api/data/sessions/devcon-7/light-client-support-in-prysm.json @@ -23,8 +23,8 @@ "rupam" ], "eventId": "devcon-7", - "slot_start": 1731474900000, - "slot_end": 1731475800000, + "slot_start": 1731475800000, + "slot_end": 1731476700000, "slot_roomId": "breakout-1", "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/lighthouse-transition-journey-from-warp-to-axum.json b/devcon-api/data/sessions/devcon-7/lighthouse-transition-journey-from-warp-to-axum.json index db831c57..21bac94a 100644 --- a/devcon-api/data/sessions/devcon-7/lighthouse-transition-journey-from-warp-to-axum.json +++ b/devcon-api/data/sessions/devcon-7/lighthouse-transition-journey-from-warp-to-axum.json @@ -23,8 +23,8 @@ "lea-narzis" ], "eventId": "devcon-7", - "slot_start": 1731473100000, - "slot_end": 1731474000000, + "slot_start": 1731474000000, + "slot_end": 1731474900000, "slot_roomId": "breakout-1", "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/liveops-for-autonomous-worlds.json b/devcon-api/data/sessions/devcon-7/liveops-for-autonomous-worlds.json index d46db1da..f7c9c544 100644 --- a/devcon-api/data/sessions/devcon-7/liveops-for-autonomous-worlds.json +++ b/devcon-api/data/sessions/devcon-7/liveops-for-autonomous-worlds.json @@ -23,8 +23,8 @@ "rasmus-svensson" ], "eventId": "devcon-7", - "slot_start": 1731567000000, - "slot_end": 1731568500000, + "slot_start": 1731579300000, + "slot_end": 1731580800000, "slot_roomId": "classroom-a", "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/mud-past-present-and-future.json b/devcon-api/data/sessions/devcon-7/mud-past-present-and-future.json new file mode 100644 index 00000000..31110073 --- /dev/null +++ b/devcon-api/data/sessions/devcon-7/mud-past-present-and-future.json @@ -0,0 +1,28 @@ +{ + "id": "mud-past-present-and-future", + "sourceId": "FE9L3P", + "title": "MUD: Past, present, and future", + "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Autonomous World", + "Frameworks", + "Gaming", + "Tooling" + ], + "language": "en", + "speakers": [ + "alvarius" + ], + "eventId": "devcon-7", + "slot_start": 1731553200000, + "slot_end": 1731554400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE" +} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json b/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json index d7653434..aa6ba6c8 100644 --- a/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json +++ b/devcon-api/data/sessions/devcon-7/redefined-interactions-transforming-user-experience-with-intents.json @@ -36,9 +36,9 @@ "resources_slides": null, "speakers": [ "agustin-grosso", - "dominik-hell", "juli-corti", "ran-hammer", + "dominik-hell", "shawn-odonaghue" ] } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/the-age-of-aggregation.json b/devcon-api/data/sessions/devcon-7/the-age-of-aggregation.json index b23576c6..0b9dfd1b 100644 --- a/devcon-api/data/sessions/devcon-7/the-age-of-aggregation.json +++ b/devcon-api/data/sessions/devcon-7/the-age-of-aggregation.json @@ -25,7 +25,8 @@ ], "language": "en", "speakers": [ - "sandeep-nailwal" + "sandeep-nailwal", + "marc-boiron" ], "eventId": "devcon-7", "slot_start": 1731645000000, diff --git a/devcon-api/data/sessions/devcon-7/tracing-integration-in-lighthouse.json b/devcon-api/data/sessions/devcon-7/tracing-integration-in-lighthouse.json index e9a20d0f..0697f6a5 100644 --- a/devcon-api/data/sessions/devcon-7/tracing-integration-in-lighthouse.json +++ b/devcon-api/data/sessions/devcon-7/tracing-integration-in-lighthouse.json @@ -19,8 +19,8 @@ "sayan" ], "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731474900000, + "slot_start": 1731474900000, + "slot_end": 1731475800000, "slot_roomId": "breakout-1", "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE" } \ No newline at end of file diff --git a/devcon-api/data/speakers/marc-boiron.json b/devcon-api/data/speakers/marc-boiron.json new file mode 100644 index 00000000..79315586 --- /dev/null +++ b/devcon-api/data/speakers/marc-boiron.json @@ -0,0 +1,8 @@ +{ + "id": "marc-boiron", + "sourceId": "WD3SKQ", + "name": "Marc Boiron", + "avatar": "", + "description": "", + "hash": "28a91fe493dfa63cd71a50b10972dd85aafa9356621c6f959d7032c349d316ec" +} \ No newline at end of file diff --git a/devcon-api/data/speakers/olivia-smith.json b/devcon-api/data/speakers/olivia-smith.json index 5dceaabc..5c996192 100644 --- a/devcon-api/data/speakers/olivia-smith.json +++ b/devcon-api/data/speakers/olivia-smith.json @@ -4,6 +4,6 @@ "name": "Olivia Smith", "avatar": "https://speak.devcon.org/media/avatars/View_recent_photos_B1ht6Dt.jpeg", "description": "Olivia Smith is the Chief Operating Officer at Moonsong Labs, where she leads operational strategy and drives growth across Moonsong’s engineering services business and venture studio. Previously, Olivia served as VP of Strategy at PureStake, the development company that helped launch Moonbeam. Before moving into blockchain, she spent four years in traditional finance. Olivia holds a joint JD/MBA from Columbia Law School and Columbia Business School.", - "twitter": "livsonchain", + "twitter": "livs__smith", "hash": "cfaf460780c5042baada3d1e6fa2df40e360b02b82118e9c902c7013e5b565fb" } \ No newline at end of file diff --git a/devcon-api/data/speakers/rachel.json b/devcon-api/data/speakers/rachel.json index c5a3d81b..95b8db88 100644 --- a/devcon-api/data/speakers/rachel.json +++ b/devcon-api/data/speakers/rachel.json @@ -2,8 +2,8 @@ "id": "rachel", "sourceId": "PXQNGF", "name": "Rachel", - "avatar": "", - "description": "", + "avatar": "https://speak.devcon.org/media/avatars/Screen_Shot_2024-11-13_at_3.32.51_AM_BzA4iPB.png", + "description": "Design for applied cryptography @ PSE + Cursive", "twitter": "rachel_aux", "hash": "f12823a5ff581bc4a96afbe44226e8cbfe3b0b49ecfe6f5e265f0f1ff6503749" } \ No newline at end of file diff --git a/devcon-api/data/speakers/vijay-mohan.json b/devcon-api/data/speakers/vijay-mohan.json index 41f212bb..476d096f 100644 --- a/devcon-api/data/speakers/vijay-mohan.json +++ b/devcon-api/data/speakers/vijay-mohan.json @@ -5,4 +5,4 @@ "avatar": "https://speak.devcon.org/media/avatars/IMG-20190708-WA0000_FZaJcX5_dB0Qie7.jpg", "description": "Vijay is an independent researcher with a Ph.D in Economics from Iowa State University. His current interests include mechanism design for blockchains and the impact of new technology on society.", "hash": "8d55527314e2b16736d4e8fd51e0848036c0162417895d42f42120d120bba468" -} +} \ No newline at end of file diff --git a/devcon-api/data/speakers/vivian-chen.json b/devcon-api/data/speakers/vivian-chen.json index c6126a80..032892e9 100644 --- a/devcon-api/data/speakers/vivian-chen.json +++ b/devcon-api/data/speakers/vivian-chen.json @@ -2,7 +2,7 @@ "id": "vivian-chen", "sourceId": "CJXMNA", "name": "Vivian Chen", - "avatar": "https://speak.devcon.org/media/avatars/Vivian_Chen_9AGSyGu.jpg", + "avatar": "https://speak.devcon.org/media/avatars/Vivian_Chen_9AGSyGu1_ACMBJkG.jpg", "description": "Vivian Chen is a human rights activist who focuses on women's, children's, digital, and democratic rights. She was Taiwan's youth representative to the United Nations Commission on Status of Women and the official delegate to APEC. Since 2015, Vivian has worked with shelters for refugees, child laborers, orphans, and marginalized communities.\r\n\r\nVivian is the founding organizer of da0, a civic tech community in Taiwan, and the founding Catalyst of Pagoda, a network for Asian changemakers, contribu", "twitter": "vvntp6", "hash": "409e7f12da94d9a72d7defb15717db4cbb099ac6a70265ebb32e8bf583888c70" diff --git a/devcon-api/data/vectors/devcon-7.json b/devcon-api/data/vectors/devcon-7.json index 02d28d7d..4dc5cdd3 100644 --- a/devcon-api/data/vectors/devcon-7.json +++ b/devcon-api/data/vectors/devcon-7.json @@ -47477,24 +47477,33 @@ "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Developer", - "onboarding" - ], "tags": [ "Open Source Software", "Public good", "Tooling" ], - "language": "en", - "speakers": [ - "austin-griffith" + "keywords": [ + "Developer", + "onboarding" ], + "duration": 5979, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "_VWF2fiXDPQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f0d63a168eb5353ce195.vtt", + "transcript_text": " The so um Some small things with that. And then we're going to go through speedrun Ethereum and we're going to kind of just look at this curriculum and kind of talk through each of the like learning moments that you'll go through when you go through Speedrun Ethereum. So let's get started with Scaffold ETH first. Scaffold ETH is a dApp developer tool. It's great for tinkering with your smart contracts and it has this auto-adapting front end that is really nice when you're tinkering with your smart contracts. And it has this auto adapting front end that is really nice when you're tinkering around with your smart contracts. So I'm going to run this. What, DevCon 2? This will be my second demo today. Maybe we'll do Foundry this time. So Scaffold ETH is a DAP building tool, like I said. It uses Next.js, Rainbow Kit, Wagme, TypeScript, and you kind of have the choice between Hardhat or Foundry. It's a great tool for prototyping. You can quickly get something out the door. I think I deployed, earlier I deployed", "eventId": "devcon-7", "slot_start": 1731398400000, "slot_end": 1731405600000, "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1obbj2bv-axqq0YxZpjvXmMW2LkNzMztiVyIBfdu3Z6Q" + "resources_presentation": "https://docs.google.com/presentation/d/1obbj2bv-axqq0YxZpjvXmMW2LkNzMztiVyIBfdu3Z6Q", + "resources_slides": null, + "speakers": [ + "austin-griffith" + ] }, "vector": [ 0, @@ -92240,11 +92249,6 @@ "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [ - "Scaffold-ETH", - "Dapp", - "App" - ], "tags": [ "Tooling", "DevEx", @@ -92254,15 +92258,29 @@ "Public good", "Tooling" ], - "language": "en", - "speakers": [ - "austin-griffith" + "keywords": [ + "Scaffold-ETH", + "Dapp", + "App" ], + "duration": 4561, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "BXimn0tony8", + "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": 1731394800000, "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1918G58t4sIlc_rPC4YAPTZbQ0BQzE8SIevAi5yPsMaA" + "resources_presentation": "https://docs.google.com/presentation/d/1918G58t4sIlc_rPC4YAPTZbQ0BQzE8SIevAi5yPsMaA", + "resources_slides": null, + "speakers": [ + "austin-griffith" + ] }, "vector": [ 0, @@ -165448,12 +165466,12 @@ "duration": 1057, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "KTY4O0VanvY", + "sources_youtubeId": "6VJYBNZioHg", "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/673356d73a168eb5357cf419.vtt", + "transcript_text": " All right, so let me get this on the right slide here. Common knowledge. So what is common knowledge? Why does it matter? So common knowledge is not just that you know I'm standing here, it's that you know that I know that you know ad infinitum. It's a very different thing than just knowing that I'm here. And a classic example of this is the Romanian Revolution in 1989. For years, everyone knew that this dictator, Chia Ceausescu, was a tyrant, but nothing ever happened. And it wasn't until actually a simple act during one of his public speeches, a live broadcast whistle that cascaded into many whistles, that a revolution began. And the key wasn't just that everybody saw, the key was not just that everybody was unhappy, but they saw that everybody else was unhappy. So we've had similar moments in American history. I'm American, so that's my history. But my contention is actually common knowledge is getting harder to get off the ground. And that's because of increasing political polarization. And while political polarization predates the internet, it certainly has been accelerated in the digital age. And why is it so bad? Well, if we can't find common ground, if we can't have shared beliefs, then collective action becomes really hard, and collective action is the stuff for political movements and also for government and legitimate governance. And so on the international stage this is really important important so unions stay unified and can differentiate their allies from their adversaries and marshal support and not collapse into the chaos of competing narratives which we seem to be trending towards. And also common knowledge lets us solve higher forms of cooperation problem, for example, like climate change that requires consensus and agreement about the facts. So since this is DevCon and an Ethereum conference, it's worth acknowledging actually that Ethereum itself is an example of a common knowledge machine. It produces or it seeks to actually produce an immutable ledger about shared global state. Another obvious example of common knowledge machines are things like blue sky, forecaster, lens, or X. These are the functional equivalent of public squares, but actually online. But of course here, common knowledge rarely ever gets off the ground, and instead we just have divisions and competing narratives about reality and which one is true. So today I want to introduce a quick mechanism and outline on the principles to sort of nudge your thoughts, and you can read more if you want in my writings. So the idea is called community posts, and everybody here who participates in some social media platform has some set of followers. And the idea is instead of blasting a post to all of your followers, you first stress test a post across different groups of followers who don't necessarily talk, listen, or agree with one another to gauge what resonates before it's widely shared. And so here's how it works. If you look at your followers, your set of followers, they actually all have differences in behavior measured by their likes, their reposts, who follows them, and who they follow, their connections. And you can aggregate this information about observed behavior using things like ZK-SNARKs and put people in clusters as represented by circles here. And the idea is that you pick a subset of uncorrelated followers on your social graph, people who behave differently on the platform, balance for reach with a minimum diversification threshold. Now, these polarity subsets aren't an echo chamber. What they are is a sampling or a random sampling of some set of your followers balanced across different perspectives. And there'll be multiple subsets to choose from. For example, you can handpick key anchors or key thought leaders or experts and then diversify against them in different combinations to fill the remaining set. Now, once you pick your subset, you send that post to the subset with a zero-knowledge proof confirming that recipients follow you without revealing your identity. Now some might disagree with the post and send ZK feedback to you, but some might actually take it further and pass it on to subsets, polarity subsets of their followers. And these rounds repeat forming a tree of polarity subsets across the social graph, which essentially pushes your post across very diverse parts of the social graph, allowing you to gauge cross-tribal appeal at every step and every layer through repost rates and feedback. And of course, if people receive this, get a notification, ZK posted by the end people you follow, or end people you follow boosted this post, and so on. Now, the final step is the post goes public. Once it gains enough support across and reaches that diversification threshold, and it's passed its social stress test, then the post goes public, and you can merge into your open feed, and anyone who has reposted it can post it to all their followers, and so on. And then, you know, any remaining divides as represented by red here on these red parts of the social graph, you can use community notes, which we're all familiar with, to bridge and add context. And this is really low-hanging fruit divides. So anyways, this is the summary of the mechanism. I think it works because essentially what you're doing is you're reversing the cycle that happens on social media of context collapse, controversy, cancellation, and capture. And these are things where social media leverages divisions to create more divisions. And you reverse that cycle with diversification, discounts, and bridging to restore common ground. Okay. I think that's it for five minutes. I can take any of your questions. Thank you, Chris. I think that's it for five minutes. I can take any of your questions. . That was kind of a complex mechanism for five minutes. Who wants to ask a question? Who wants to ask a question? Here, please. This is amazing. What do we do next? What's like a next step here? Yeah, so there are a lot of experiments with social graphs right now in Web3. FarCaster and Lens are an example. And so you can leverage like ZK-SNARKs, zero knowledge proofs to actually calculate this information without revealing the identities and participants in a social graph and start leverage like ZKStarks, Zero Knowledge Proofs, to actually calculate this information without revealing the identities and participants in a social graph and start to create a more meaningful parallel attention feed to show, OK, what are posts where there's wide agreement on? And instead of focusing on the attention and the rage bait that comes from a global attention auction, you can focus your attention on, OK, well, what are the things where there's agreement and then build on that agreement? Yeah? We can have one more question. Do you envision this being applicable to, like, more popular social media, like maybe a plug-in for Twitter or whatever? Yeah, it could apply to any social media. It could apply, it's a roadmap for making X a common knowledge machine. I think that actually was always the aspiration around a public square and the Ceausescu example. It's also applicable to TikTok. It's applicable to really any social network. And it's just a more intelligent attention mechanism, right, that gets us, that sort of reverses the cycle of let me, you know, hit my dopamine receptors with division towards, let me see what I can find common ground with and build on that. Okay. Thank you, everybody. Thank you. Thank you. I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool So for this Wasim, he will not He don't want to use the modern leader Yes And you just growing up and then you're all, you know, like, in the state, and then you're going down, and after that, you just wait until it wasn't finished over. You know, just like that. Okay. Okay. Okay. Are you ready? Oh, yes, I am. Okay, everyone. Next, we have The Shane Male Gaze by Wazim Z. Alcindi. Please, give him a warm welcome. Hello, everybody. It's slightly out of place to have such cheerful music introducing this talk perhaps so the title of it is called The Chainmail Gaze and hopefully the reasons for that will become apparent as we go on but I'm sure you've all heard of the mail gaze and the kind of externalities and you know unfavorable things that come with that but what about the chain male gaze well hopefully we'll find out not got very long so i'll try to you know give you a survey of what's actually quite extensive anthropological and philosophical research project okay some pictures of big strong men and their swords looking into the distance, perhaps thinking about lands to conquer. Short poetic refrain, the church and the network, zeal and time, death and money, all sides of the same coin. a phwysig, pob rhan o'r un coin. Rwy'n hoff i siarad â chi am brosiect cymhwysol sy'n arwain at y lle rydyn ni'n mynd i, a'i enw'n enw'n ymwneud â'r ddyfyniadau ar gyfer cyfrif, yn edrych ar y in the technology space that might not be immediately apparent. For as long as there's been financial capital, risk and speculation have orbited, manipulated and harnessed it. As narrative feedback machines, simultaneously reading and rewriting realities, markets exist as a distributed conversation among speculators driven by profit motives and appetite for divination and prophecy. Today, new strains of techno-colonialism are emerging, which are the latest of a series of echoes throughout Western history. An ascendant cabal of technology elites are attempting to reshape the world in their favor whilst hiding in plain sight behind the technologies that have enriched them. Theirs is a Promethean zealotry without faith, affecting an aura of divine sanction for the purposes of elevating the ego, enriching the chosen ones, and creating empires of various stripes. But was it not? Always so. I want to read you a short story, fictional speculation, about where we might be going in the future. It's called Seething Like a State. Decentralization has a cost, the price of anarchy. The price is always due, but the rewards weren't cheap to reap. So solid, CCRU. What most did not expect was that payment would become due at the grandest scales of governance. The West failure state, forged under the fire of peer pressure, was ambushed by upstart modes of power, opening new vistas of communication, commodification and communion. The orientations that nation states had used to enshrine their power only made it easier to undermine them. The bigger they were, the harder they fell. Brextopia, the European Union, NATO's cave, the United State machine, all returned to dust. The decline of the nation state in the roaring 20s became a canon of canonicity for an entire generation of sole traders. It wasn't even just the bit leavers. In those days, there were many networks, many messiahs, many ideologics, all with their own profit motives. So many of you have doubtless heard of this concept of the network state that has emerged in the last few years. Exit fantasies, arguably fueled by the failure or the shortcomings the shortfall of the full promise and the dream of web3 i'm going to read you a short section from belagi's universe self self-titled book from 2022 a network state is a social network with a moral innovation a sense of national consciousness a recognized recognized founder, a capacity for collective action, an in-person level of civility, an integrated cryptocurrency, a consensual government limited by a social smart contract, an archipelago of crowdfunded physical territories, a virtual capital, and an on-chain census that proves a large enough population, income, and real estate footprint to attain a measure of diplomatic recognition. The magic words in here are recognized founder and diplomatic recognition, and territory, I would say. So these projects carry echoes, in my mind at least, of some of the earliest expeditions set out from the West in search of new territories to conquer and subjugate. So many of you have doubtless heard of things like Liberland, Sealand, Seasteading Institutes. This is the Zahidi-designed Metaverse HQ of Liberland on screen here. There's been so many attempts to make like crypto islands, Bitcoin cruise ships, and they've all failed. It's quite interesting. But what seems to be different now is the level of capital on hand as a result of market success of these technologies to the people that want to reshape the map of the world in their own, you know, to their own preferences, into their own cause. We know that leaders of nation states, we even have leaders of nation states that are cheerleading some of these technologies. Nayib Keri, the authoritarian strongman in El Salvador, would like to build a Bitcoin city financed by volcano bonds in his country. He's not done it yet. But meanwhile, he's removed the judiciary, removed term limits, and instituted one-party rule. And most of the Bitcoins are cheering this on. So I ask myself, are we still in this for the freedom? And now, you know, made possible by Ethereum, DAOs, and all the rest of it, we have projects like Aleph, Urbit, and even Praxis. Praxis on the left and Prospera on the right. So these projects are trying to build physical cities, private territories, network states, or at least what may develop into the Bellagio concept of the nation state. And it's at this point I want to introduce the chainmail gaze. Today's tech overlords are the descendants of Europe's crusaders well-financed zealous fanatics wreaking destruction on the planetary other in the name of their greater good the Vatican sponsored waves of Levantine invasions that began in the late 11th century with a midwife of capitalism, colonialism, and technology as we know it today. With the network state organizational concept, a cadre of powerful ideologues blessed with tokenized wealth, a toying with the prospect of reshaping national frontiers, mirroring the desires of Frankish noblemen and their nightly orders in the Levant a thousand years ago. And that's all the time I have. Seven minutes for a thousand years of Western history. Thank you very much.", "eventId": "devcon-7", "slot_start": 1731409200000, "slot_end": 1731409800000, @@ -193947,15 +193965,15 @@ "TEE", "Dark DAO" ], - "duration": 1516, + "duration": 1515, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "KSDNYHB3xto", + "sources_youtubeId": "iU-2dwVVagk", "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/67335b2b3a168eb53591f192.vtt", + "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.", "eventId": "devcon-7", "slot_start": 1731405600000, "slot_end": 1731407400000, @@ -265767,7 +265785,7 @@ "duration": 1518, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "O0-GOTEUQyY", + "sources_youtubeId": "Bey043R_52k", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, @@ -337572,9 +337590,6 @@ "audience": "Engineering", "featured": true, "doNotRecord": false, - "keywords": [ - "Farcaster" - ], "tags": [ "Developer Infrastructure", "Social", @@ -337582,15 +337597,27 @@ "Developer Infrastructure", "Social" ], - "language": "en", - "speakers": [ - "horsefacts" + "keywords": [ + "Farcaster" ], + "duration": 5086, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "LnEpR575FRA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", "slot_start": 1731400800000, "slot_end": 1731406200000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M" + "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M", + "resources_slides": null, + "speakers": [ + "horsefacts" + ] }, "vector": [ 0, @@ -467648,26 +467675,35 @@ "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "RIP", - "L1SLOAD", - "Precompile" - ], "tags": [ "Developer Infrastructure", "DevEx", "Rollups" ], - "language": "en", - "speakers": [ - "peter-garamvolgyi", - "rh" + "keywords": [ + "RIP", + "L1SLOAD", + "Precompile" ], + "duration": 5064, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "R9-QpN-hr6w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", "slot_start": 1731394800000, "slot_end": 1731400200000, "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E" + "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E", + "resources_slides": null, + "speakers": [ + "peter-garamvolgyi", + "rh" + ] }, "vector": [ 0, @@ -555725,12 +555761,12 @@ "duration": 1542, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "qEUAUzVf5v8", + "sources_youtubeId": "MmjAhdEbnV0", "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/673358ad3a168eb535865df1.vtt", + "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.", "eventId": "devcon-7", "slot_start": 1731407400000, "slot_end": 1731409200000, @@ -612598,9 +612634,6 @@ "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "DeFi" - ], "tags": [ "User Experience", "Intents", @@ -612608,19 +612641,31 @@ "Intents", "User Experience" ], + "keywords": [ + "DeFi" + ], + "duration": 2896, "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "hId-FQUOpJ0", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731406200000, + "slot_end": 1731409800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU", + "resources_slides": null, "speakers": [ "agustin-grosso", + "dominik-hell", "juli-corti", "ran-hammer", - "dominik-hell", "shawn-odonaghue" - ], - "eventId": "devcon-7", - "slot_start": 1731406200000, - "slot_end": 1731409800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU" + ] }, "vector": [ 0, @@ -642400,10 +642445,6 @@ "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Incident", - "Response" - ], "tags": [ "Coordination", "Security", @@ -642412,16 +642453,29 @@ "Coordination", "Security" ], - "language": "en", - "speakers": [ - "isaac-patka", - "kelsie-nabben" + "keywords": [ + "Incident", + "Response" ], + "duration": 1350, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "9UBmda-mqGs", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732febd80d989c5b7b49fc9.vtt", + "transcript_text": " And I also lead the War Games initiative for the Security Alliance. I'll give a brief introduction to just what the Security Alliance is and what the various initiatives are, because I think it's actually pretty relevant also after the first talk about ENS and data sharing. And so the top initiative here is actually called the SEAL-ISAC, which is not me, I'm SEAL-ISAC. This is the Information Security something something, which basically this is like a shared database between many different companies where they can share data on like DPRK threat actors or phishing data or bad domains. There's SEAL War Games, which is the initiative that I lead, where we prepare protocol teams for incident response through both tabletop simulations and then live simulations on forked environments. SEAL also operates SEAL 911, the emergency hotline, if your protocol is under attack or if you have discovered a vulnerability in a protocol and need to get in touch with a security expert as fast as possible. The Safe Harbor Agreement, which is legal protection if you're a white hat hacker and you're acting benevolently in an urgent situation to rescue funds from a protocol. Think Nomad Bridge hack a few years ago if you were trying to save money, but maybe you were worried because you thought that you'd be sued for hacking during because it'd be impossible to distinguish. The White Hat Safe Harbor Agreement exists to protect white hat hackers in those situations and a legal defense fund in case they sue you anyway. So today what we'll talk about primarily is war games. So what are these war games and why do we do them? I'll have some links to resources on how you can work with us. There's a lot of open source toolkits and we also run these as like a public good throughout the space. We'll be talking through some best practices that I've learned from working with some of the major protocols in the ecosystem and then just briefly show you what this new toolkit is that we released so you can run these yourself if you would like. So what are wargames? These are cybersecurity exercises for Web3. I've heard traditional cybersecurity folks call these something like a purple team exercise, where we're not exactly red team, blue team, but we're basically just trying to stress test these teams and understand how they behave under pressure. And so we want to help teams practice for these high-pressure situations before they actually happen. We want to be able to test both the technical side of their team and their social resilience. And we're not just trying to help cause them to panic, but we want them to practice emergency response. A lot of the reason why we started doing this was a few years ago. So the security lines was started by Sam Sun, and he was pulled into so many war rooms where it seemed like, I guess, from what I've heard, teams just completely melting down and not really being exactly prepared for what would happen. So what could we actually do to help put them in that situation before that inevitably happens? So war games take place through three phases. I do a lot of intelligence gathering, which really just means reading every document that the protocol's ever published, understand their contracts, understand how it works. We do a tabletop exercise where we talk through various scenarios with them and understand how they would have detected them, what they would do, who's in charge, and how would they have fixed something. And then what I think is the most fun is we do a live simulation. So we set up a forked environment, we run all of their contracts, we write all of their UIs, we run all of their monitoring, and then they actually have to coordinate in real time to defend and respond as if it was a real incident. And we tend to find a lot of things that they can improve through that process, and it also just helps the team build trust in each other so that they know when an incident goes down for real, I can trust my team to be there. So a big reason why we do this is because more and more hacks are due to operational failures, not smart contract bugs. That's a really, I think, good sign that we're making fewer and fewer dumb mistakes on the smart contract side. However, as all of the stuff that we're building is becoming such a critical component of global financial infrastructure, the stakes are higher to actually operationally be strong as well. And so whether that's things like supply chain attacks or social engineering, it's much harder now than just not including dumb bugs in your smart contracts. So these are cross-functional exercises. We're not just working with the development team. They're of course a core part of it, but we're also tending to work with their auditors if they're a big protocol that has a guardian multi-sig that's in charge of pausing the protocol in case of emergency. We of course work with them. Communications team is actually essential so that we know what would they be communicating out to the public and when during an incident and legal so that they can say, okay, if we were to take this action perhaps to protect the users of our protocol, can we do that? Should we do that? And what should we be saying? The conversations between communications, legal, and devs should really be things that are figured out in advance so that during the incident,'re not thinking like do we tweet out that we're under attack right now or do we say something cryptic or what do we say like these are things that you can just have in a playbook so that you don't have to think about it in the moment. We've worked with a number of products of protocols so far but the purpose of this slide is also just to show you like why teams are working with us, it's because teams are growing. These are global teams, and it's really hard to prepare for this type of thing. There's many ways to engage with us. If you're a protocol that wants to work with a security alliance and have a drill performed with you, there's a form on the website, and there's also open source resources for you to be able to run these yourself. So this is a quote that I had a really hard time attributing. The internet said it was either like a Greek poet or the Navy Seals, but I think that it really like stands to to show like why we do this and it's that under pressure we don't rise to the occasion, we sink to our level of training. Yeah I think that that speaks to why we do this. So each one of these builds is quite different. A lot of protocols have various sorts of custom infrastructure and monitoring. So every time we do this, we end up having to build a lot of things. And we've tried to combine all of those tools and things that we've learned on how to run these simulations into this drill template that you can see here. It's on the Security Alliance GitHub repository. But what are the things that we do to make the environment feel realistic? So we of course have to run a network fork. We're usually either doing that with Anvil or with Tenderly. We have to run a block explorer, so we're either running Block Scout or using a virtual test net. We're running monitoring, so it's essential to mirror the same monitoring that you would have on main net.", "eventId": "devcon-7", "slot_start": 1731390600000, "slot_end": 1731392400000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE" + "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE", + "resources_slides": null, + "speakers": [ + "isaac-patka", + "kelsie-nabben" + ] }, "vector": [ 6, diff --git a/devcon-api/data/vectors/dictionary.json b/devcon-api/data/vectors/dictionary.json index 03808e71..37b8690a 100644 --- a/devcon-api/data/vectors/dictionary.json +++ b/devcon-api/data/vectors/dictionary.json @@ -544,9 +544,9 @@ "daniel-marzec", "garm", "agustin-grosso", + "dominik-hell", "juli-corti", "ran-hammer", - "dominik-hell", "shawn-odonaghue", "joseph-low", "hazel-devjani", From 83cf7e0dc69e5c33e9f33dd5d4cda00f6626e2f2 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:20:30 +0700 Subject: [PATCH 05/17] [skip deploy] PUT /sessions/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power --- ...o-real-decentralization-in-a-world-of-centralized-power.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json b/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json index 46b49fe1..bae45804 100644 --- a/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json +++ b/devcon-api/data/sessions/devcon-7/eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power.json @@ -26,7 +26,7 @@ "duration": 1502, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "kSrjley2POk", + "sources_youtubeId": "ySVYt6MUrHM", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, From 30f5bf10eb3cb3b3a97c8e13aeac5d74f9557cd6 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:20:31 +0700 Subject: [PATCH 06/17] [skip deploy] PUT /sessions/keynote-title-redacted --- devcon-api/data/sessions/devcon-7/keynote-title-redacted.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json b/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json index 3170f88e..fc90f5a5 100644 --- a/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json +++ b/devcon-api/data/sessions/devcon-7/keynote-title-redacted.json @@ -25,7 +25,7 @@ "duration": 1553, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "Gjuenkv1zrw", + "sources_youtubeId": "Plvy7fgFCm4", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, From e2a9dd76e4b2960422264970834103c42ca44212 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:24:06 +0700 Subject: [PATCH 07/17] [skip deploy] PUT /sessions/the-shape-of-protocols-to-come --- .../the-shape-of-protocols-to-come.json | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/the-shape-of-protocols-to-come.json b/devcon-api/data/sessions/devcon-7/the-shape-of-protocols-to-come.json index 45b1225b..b85962e8 100644 --- a/devcon-api/data/sessions/devcon-7/the-shape-of-protocols-to-come.json +++ b/devcon-api/data/sessions/devcon-7/the-shape-of-protocols-to-come.json @@ -9,19 +9,28 @@ "audience": "Engineering", "featured": true, "doNotRecord": false, - "keywords": [], "tags": [ "Ethereum Roadmap", "Protocol Design", "Use Cases" ], + "keywords": [], + "duration": 1402, "language": "en", - "speakers": [ - "tim-beiko" - ], + "sources_swarmHash": "", + "sources_youtubeId": "t_2ZIfF9gMc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", "slot_start": 1731409200000, "slot_end": 1731411000000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw" + "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw", + "resources_slides": null, + "speakers": [ + "tim-beiko" + ] } \ No newline at end of file From d84a3a3aac3401336f92c2d505f9b69b93d73d2a Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:25:11 +0700 Subject: [PATCH 08/17] [skip deploy] PUT /sessions/the-history-and-philosophy-of-cypherpunk --- ...-history-and-philosophy-of-cypherpunk.json | 31 ++++++++++++------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json b/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json index d1186fa0..72c68fbb 100644 --- a/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json +++ b/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json @@ -9,11 +9,6 @@ "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "mixnets", - "cypherpunk", - "cryptoanarchist" - ], "tags": [ "Anonymity", "Censorship Resistance", @@ -25,15 +20,29 @@ "Politics", "Values" ], - "language": "en", - "speakers": [ - "max-hampshire", - "harry-halpin", - "iness-ben-guirat" + "keywords": [ + "mixnets", + "cypherpunk", + "cryptoanarchist" ], + "duration": 1555, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "prXQJSp_H8A", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt", + "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big", "eventId": "devcon-7", "slot_start": 1731407400000, "slot_end": 1731409200000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo" + "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo", + "resources_slides": null, + "speakers": [ + "harry-halpin", + "iness-ben-guirat", + "max-hampshire" + ] } \ No newline at end of file From 9d859bba933ca1429616e9cd7c163bc40e3a0ec3 Mon Sep 17 00:00:00 2001 From: wslyvh Date: Wed, 13 Nov 2024 09:28:51 +0700 Subject: [PATCH 09/17] schedule --- ...as-unlock-exponential-wealth-via-a-computable-economy.json | 4 ++-- devcon-api/data/speakers/amir-taaki.json | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy.json b/devcon-api/data/sessions/devcon-7/how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy.json index b5aafce6..5c354d1d 100644 --- a/devcon-api/data/sessions/devcon-7/how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy.json +++ b/devcon-api/data/sessions/devcon-7/how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy.json @@ -35,7 +35,7 @@ "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU", "resources_slides": null, "speakers": [ - "jason-potts", - "justin-banon" + "justin-banon", + "jason-potts" ] } \ No newline at end of file diff --git a/devcon-api/data/speakers/amir-taaki.json b/devcon-api/data/speakers/amir-taaki.json index 6220b0ac..0c8e9836 100644 --- a/devcon-api/data/speakers/amir-taaki.json +++ b/devcon-api/data/speakers/amir-taaki.json @@ -7,4 +7,4 @@ "twitter": "narodism", "github": "genjix", "hash": "d3afd051992e1573726a19a7207c348b32f31e9b805279a17fc7b087209df977" -} +} \ No newline at end of file From 832057a285026122621f619ca7bfdaa2326cdaf2 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:29:17 +0700 Subject: [PATCH 10/17] [skip deploy] PUT /sessions/common-knowledge-machines --- .../data/sessions/devcon-7/common-knowledge-machines.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json b/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json index a0a0b593..2d652120 100644 --- a/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json +++ b/devcon-api/data/sessions/devcon-7/common-knowledge-machines.json @@ -20,15 +20,15 @@ "Stellar", "Punk" ], - "duration": 1057, + "duration": 468, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "6VJYBNZioHg", + "sources_youtubeId": "B1oh1WrU-7g", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673356d73a168eb5357cf419.vtt", - "transcript_text": " All right, so let me get this on the right slide here. Common knowledge. So what is common knowledge? Why does it matter? So common knowledge is not just that you know I'm standing here, it's that you know that I know that you know ad infinitum. It's a very different thing than just knowing that I'm here. And a classic example of this is the Romanian Revolution in 1989. For years, everyone knew that this dictator, Chia Ceausescu, was a tyrant, but nothing ever happened. And it wasn't until actually a simple act during one of his public speeches, a live broadcast whistle that cascaded into many whistles, that a revolution began. And the key wasn't just that everybody saw, the key was not just that everybody was unhappy, but they saw that everybody else was unhappy. So we've had similar moments in American history. I'm American, so that's my history. But my contention is actually common knowledge is getting harder to get off the ground. And that's because of increasing political polarization. And while political polarization predates the internet, it certainly has been accelerated in the digital age. And why is it so bad? Well, if we can't find common ground, if we can't have shared beliefs, then collective action becomes really hard, and collective action is the stuff for political movements and also for government and legitimate governance. And so on the international stage this is really important important so unions stay unified and can differentiate their allies from their adversaries and marshal support and not collapse into the chaos of competing narratives which we seem to be trending towards. And also common knowledge lets us solve higher forms of cooperation problem, for example, like climate change that requires consensus and agreement about the facts. So since this is DevCon and an Ethereum conference, it's worth acknowledging actually that Ethereum itself is an example of a common knowledge machine. It produces or it seeks to actually produce an immutable ledger about shared global state. Another obvious example of common knowledge machines are things like blue sky, forecaster, lens, or X. These are the functional equivalent of public squares, but actually online. But of course here, common knowledge rarely ever gets off the ground, and instead we just have divisions and competing narratives about reality and which one is true. So today I want to introduce a quick mechanism and outline on the principles to sort of nudge your thoughts, and you can read more if you want in my writings. So the idea is called community posts, and everybody here who participates in some social media platform has some set of followers. And the idea is instead of blasting a post to all of your followers, you first stress test a post across different groups of followers who don't necessarily talk, listen, or agree with one another to gauge what resonates before it's widely shared. And so here's how it works. If you look at your followers, your set of followers, they actually all have differences in behavior measured by their likes, their reposts, who follows them, and who they follow, their connections. And you can aggregate this information about observed behavior using things like ZK-SNARKs and put people in clusters as represented by circles here. And the idea is that you pick a subset of uncorrelated followers on your social graph, people who behave differently on the platform, balance for reach with a minimum diversification threshold. Now, these polarity subsets aren't an echo chamber. What they are is a sampling or a random sampling of some set of your followers balanced across different perspectives. And there'll be multiple subsets to choose from. For example, you can handpick key anchors or key thought leaders or experts and then diversify against them in different combinations to fill the remaining set. Now, once you pick your subset, you send that post to the subset with a zero-knowledge proof confirming that recipients follow you without revealing your identity. Now some might disagree with the post and send ZK feedback to you, but some might actually take it further and pass it on to subsets, polarity subsets of their followers. And these rounds repeat forming a tree of polarity subsets across the social graph, which essentially pushes your post across very diverse parts of the social graph, allowing you to gauge cross-tribal appeal at every step and every layer through repost rates and feedback. And of course, if people receive this, get a notification, ZK posted by the end people you follow, or end people you follow boosted this post, and so on. Now, the final step is the post goes public. Once it gains enough support across and reaches that diversification threshold, and it's passed its social stress test, then the post goes public, and you can merge into your open feed, and anyone who has reposted it can post it to all their followers, and so on. And then, you know, any remaining divides as represented by red here on these red parts of the social graph, you can use community notes, which we're all familiar with, to bridge and add context. And this is really low-hanging fruit divides. So anyways, this is the summary of the mechanism. I think it works because essentially what you're doing is you're reversing the cycle that happens on social media of context collapse, controversy, cancellation, and capture. And these are things where social media leverages divisions to create more divisions. And you reverse that cycle with diversification, discounts, and bridging to restore common ground. Okay. I think that's it for five minutes. I can take any of your questions. Thank you, Chris. I think that's it for five minutes. I can take any of your questions. . That was kind of a complex mechanism for five minutes. Who wants to ask a question? Who wants to ask a question? Here, please. This is amazing. What do we do next? What's like a next step here? Yeah, so there are a lot of experiments with social graphs right now in Web3. FarCaster and Lens are an example. And so you can leverage like ZK-SNARKs, zero knowledge proofs to actually calculate this information without revealing the identities and participants in a social graph and start leverage like ZKStarks, Zero Knowledge Proofs, to actually calculate this information without revealing the identities and participants in a social graph and start to create a more meaningful parallel attention feed to show, OK, what are posts where there's wide agreement on? And instead of focusing on the attention and the rage bait that comes from a global attention auction, you can focus your attention on, OK, well, what are the things where there's agreement and then build on that agreement? Yeah? We can have one more question. Do you envision this being applicable to, like, more popular social media, like maybe a plug-in for Twitter or whatever? Yeah, it could apply to any social media. It could apply, it's a roadmap for making X a common knowledge machine. I think that actually was always the aspiration around a public square and the Ceausescu example. It's also applicable to TikTok. It's applicable to really any social network. And it's just a more intelligent attention mechanism, right, that gets us, that sort of reverses the cycle of let me, you know, hit my dopamine receptors with division towards, let me see what I can find common ground with and build on that. Okay. Thank you, everybody. Thank you. Thank you. I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool So for this Wasim, he will not He don't want to use the modern leader Yes And you just growing up and then you're all, you know, like, in the state, and then you're going down, and after that, you just wait until it wasn't finished over. You know, just like that. Okay. Okay. Okay. Are you ready? Oh, yes, I am. Okay, everyone. Next, we have The Shane Male Gaze by Wazim Z. Alcindi. Please, give him a warm welcome. Hello, everybody. It's slightly out of place to have such cheerful music introducing this talk perhaps so the title of it is called The Chainmail Gaze and hopefully the reasons for that will become apparent as we go on but I'm sure you've all heard of the mail gaze and the kind of externalities and you know unfavorable things that come with that but what about the chain male gaze well hopefully we'll find out not got very long so i'll try to you know give you a survey of what's actually quite extensive anthropological and philosophical research project okay some pictures of big strong men and their swords looking into the distance, perhaps thinking about lands to conquer. Short poetic refrain, the church and the network, zeal and time, death and money, all sides of the same coin. a phwysig, pob rhan o'r un coin. Rwy'n hoff i siarad â chi am brosiect cymhwysol sy'n arwain at y lle rydyn ni'n mynd i, a'i enw'n enw'n ymwneud â'r ddyfyniadau ar gyfer cyfrif, yn edrych ar y in the technology space that might not be immediately apparent. For as long as there's been financial capital, risk and speculation have orbited, manipulated and harnessed it. As narrative feedback machines, simultaneously reading and rewriting realities, markets exist as a distributed conversation among speculators driven by profit motives and appetite for divination and prophecy. Today, new strains of techno-colonialism are emerging, which are the latest of a series of echoes throughout Western history. An ascendant cabal of technology elites are attempting to reshape the world in their favor whilst hiding in plain sight behind the technologies that have enriched them. Theirs is a Promethean zealotry without faith, affecting an aura of divine sanction for the purposes of elevating the ego, enriching the chosen ones, and creating empires of various stripes. But was it not? Always so. I want to read you a short story, fictional speculation, about where we might be going in the future. It's called Seething Like a State. Decentralization has a cost, the price of anarchy. The price is always due, but the rewards weren't cheap to reap. So solid, CCRU. What most did not expect was that payment would become due at the grandest scales of governance. The West failure state, forged under the fire of peer pressure, was ambushed by upstart modes of power, opening new vistas of communication, commodification and communion. The orientations that nation states had used to enshrine their power only made it easier to undermine them. The bigger they were, the harder they fell. Brextopia, the European Union, NATO's cave, the United State machine, all returned to dust. The decline of the nation state in the roaring 20s became a canon of canonicity for an entire generation of sole traders. It wasn't even just the bit leavers. In those days, there were many networks, many messiahs, many ideologics, all with their own profit motives. So many of you have doubtless heard of this concept of the network state that has emerged in the last few years. Exit fantasies, arguably fueled by the failure or the shortcomings the shortfall of the full promise and the dream of web3 i'm going to read you a short section from belagi's universe self self-titled book from 2022 a network state is a social network with a moral innovation a sense of national consciousness a recognized recognized founder, a capacity for collective action, an in-person level of civility, an integrated cryptocurrency, a consensual government limited by a social smart contract, an archipelago of crowdfunded physical territories, a virtual capital, and an on-chain census that proves a large enough population, income, and real estate footprint to attain a measure of diplomatic recognition. The magic words in here are recognized founder and diplomatic recognition, and territory, I would say. So these projects carry echoes, in my mind at least, of some of the earliest expeditions set out from the West in search of new territories to conquer and subjugate. So many of you have doubtless heard of things like Liberland, Sealand, Seasteading Institutes. This is the Zahidi-designed Metaverse HQ of Liberland on screen here. There's been so many attempts to make like crypto islands, Bitcoin cruise ships, and they've all failed. It's quite interesting. But what seems to be different now is the level of capital on hand as a result of market success of these technologies to the people that want to reshape the map of the world in their own, you know, to their own preferences, into their own cause. We know that leaders of nation states, we even have leaders of nation states that are cheerleading some of these technologies. Nayib Keri, the authoritarian strongman in El Salvador, would like to build a Bitcoin city financed by volcano bonds in his country. He's not done it yet. But meanwhile, he's removed the judiciary, removed term limits, and instituted one-party rule. And most of the Bitcoins are cheering this on. So I ask myself, are we still in this for the freedom? And now, you know, made possible by Ethereum, DAOs, and all the rest of it, we have projects like Aleph, Urbit, and even Praxis. Praxis on the left and Prospera on the right. So these projects are trying to build physical cities, private territories, network states, or at least what may develop into the Bellagio concept of the nation state. And it's at this point I want to introduce the chainmail gaze. Today's tech overlords are the descendants of Europe's crusaders well-financed zealous fanatics wreaking destruction on the planetary other in the name of their greater good the Vatican sponsored waves of Levantine invasions that began in the late 11th century with a midwife of capitalism, colonialism, and technology as we know it today. With the network state organizational concept, a cadre of powerful ideologues blessed with tokenized wealth, a toying with the prospect of reshaping national frontiers, mirroring the desires of Frankish noblemen and their nightly orders in the Levant a thousand years ago. And that's all the time I have. Seven minutes for a thousand years of Western history. Thank you very much.", + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", "slot_start": 1731409200000, "slot_end": 1731409800000, From 45814f78a36960048bfb21ee1d54f0a3587cd4e9 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:32:26 +0700 Subject: [PATCH 11/17] [skip deploy] PUT /sessions/programmable-cryptography-and-the-future-of-the-internet --- ...rogrammable-cryptography-and-the-future-of-the-internet.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json index f9b202b7..888a4ea2 100644 --- a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json +++ b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json @@ -16,7 +16,7 @@ "duration": 3349, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "PSs8d_ZzFCk", + "sources_youtubeId": "DzDtkThlbQI", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, From 8e944aa446dca97e590bb84705b8065c63a44bda Mon Sep 17 00:00:00 2001 From: wslyvh Date: Wed, 13 Nov 2024 10:00:09 +0700 Subject: [PATCH 12/17] remove id --- ...-cryptography-and-the-future-of-the-internet.json | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json index 888a4ea2..9f825e7d 100644 --- a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json +++ b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json @@ -10,13 +10,11 @@ "featured": false, "doNotRecord": false, "tags": [], - "keywords": [ - "None" - ], + "keywords": ["None"], "duration": 3349, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "DzDtkThlbQI", + "sources_youtubeId": "", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, @@ -28,7 +26,5 @@ "slot_roomId": "main-stage", "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", "resources_slides": null, - "speakers": [ - "justin-glibert" - ] -} \ No newline at end of file + "speakers": ["justin-glibert"] +} From 67800ea6cd9f231438f8d5bb1b8658975166fe87 Mon Sep 17 00:00:00 2001 From: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 03:54:13 +0000 Subject: [PATCH 13/17] [action] Pretalx Sync --- devcon-api/data/events/devcon-7.json | 2 +- .../devcon-7/eth-escape-winner-revealed.json | 23 + ...e-the-next-10-years-of-web3-in-africa.json | 3 +- ...graphy-and-the-future-of-the-internet.json | 10 +- .../devcon-7/robust-restaking-networks.json | 31 - .../sessions/devcon-7/securing-ethereum.json | 26 + ...enge.json => speed-hacking-challenge.json} | 6 +- ...-history-and-philosophy-of-cypherpunk.json | 4 +- .../data/speakers/julian-sutherland.json | 2 +- .../data/speakers/michael-lewellen.json | 10 + devcon-api/data/speakers/michael-okeeffe.json | 8 + devcon-api/data/speakers/neville-grech.json | 8 + devcon-api/data/speakers/pietro-carta.json | 8 + devcon-api/data/speakers/vivian-chen.json | 2 +- devcon-api/data/vectors/devcon-7.json | 40607 +++++++++------- devcon-api/data/vectors/dictionary.json | 9 +- 16 files changed, 22124 insertions(+), 18635 deletions(-) create mode 100644 devcon-api/data/sessions/devcon-7/eth-escape-winner-revealed.json delete mode 100644 devcon-api/data/sessions/devcon-7/robust-restaking-networks.json create mode 100644 devcon-api/data/sessions/devcon-7/securing-ethereum.json rename devcon-api/data/sessions/devcon-7/{cls-eth-escape-speed-hacking-challenge.json => speed-hacking-challenge.json} (85%) create mode 100644 devcon-api/data/speakers/michael-lewellen.json create mode 100644 devcon-api/data/speakers/michael-okeeffe.json create mode 100644 devcon-api/data/speakers/neville-grech.json create mode 100644 devcon-api/data/speakers/pietro-carta.json diff --git a/devcon-api/data/events/devcon-7.json b/devcon-api/data/events/devcon-7.json index cff9bcb6..3d5925b5 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": "1731463427614" + "version": "1731469314581" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/eth-escape-winner-revealed.json b/devcon-api/data/sessions/devcon-7/eth-escape-winner-revealed.json new file mode 100644 index 00000000..77a3da61 --- /dev/null +++ b/devcon-api/data/sessions/devcon-7/eth-escape-winner-revealed.json @@ -0,0 +1,23 @@ +{ + "id": "eth-escape-winner-revealed", + "sourceId": "WXS8BH", + "title": "ETH Escape Winner Revealed", + "description": "We'll announce the winner of ETH Escape.", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "michael-okeeffe" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731580200000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1lSwPhaKp0iIdGqbNHH0Wq_hG_vGPCW1ja_5qbLVLScg" +} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/keynote-the-next-10-years-of-web3-in-africa.json b/devcon-api/data/sessions/devcon-7/keynote-the-next-10-years-of-web3-in-africa.json index ba9de38c..abb560c7 100644 --- a/devcon-api/data/sessions/devcon-7/keynote-the-next-10-years-of-web3-in-africa.json +++ b/devcon-api/data/sessions/devcon-7/keynote-the-next-10-years-of-web3-in-africa.json @@ -22,7 +22,8 @@ ], "keywords": [ "Africa", - "Mass adoption" + "Mass adoption", + "" ], "duration": 1531, "language": "en", diff --git a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json index 7f9176e3..a4fe8406 100644 --- a/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json +++ b/devcon-api/data/sessions/devcon-7/programmable-cryptography-and-the-future-of-the-internet.json @@ -10,7 +10,9 @@ "featured": false, "doNotRecord": false, "tags": [], - "keywords": ["None"], + "keywords": [ + "None" + ], "duration": 3349, "language": "en", "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c", @@ -26,5 +28,7 @@ "slot_roomId": "main-stage", "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", "resources_slides": null, - "speakers": ["justin-glibert"] -} + "speakers": [ + "justin-glibert" + ] +} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/robust-restaking-networks.json b/devcon-api/data/sessions/devcon-7/robust-restaking-networks.json deleted file mode 100644 index e966bd87..00000000 --- a/devcon-api/data/sessions/devcon-7/robust-restaking-networks.json +++ /dev/null @@ -1,31 +0,0 @@ -{ - "id": "robust-restaking-networks", - "sourceId": "MERZWK", - "title": "Robust Restaking Networks", - "description": "We study the risks of validator reuse across multiple services in a restaking protocol. We characterize the robust security of a restaking network as a function of the buffer between the costs and profits from attacks. We also provide local analogs of these guarantees that apply specifically for a target service or coalition of services. Our results suggest measures of robustness that could be exposed to the participants in a restaking protocol. Full paper: https://arxiv.org/abs/2407.21785", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Risk", - "Measurement", - "and", - "Mitigation" - ], - "tags": [ - "Economics", - "Restaking" - ], - "language": "en", - "speakers": [ - "naveen-durvasula" - ], - "eventId": "devcon-7", - "slot_start": 1731486000000, - "slot_end": 1731486600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19pt0uKTgDWFeqwxxWBjlyG912sJ3Ez2L29Niax82m9w" -} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/securing-ethereum.json b/devcon-api/data/sessions/devcon-7/securing-ethereum.json new file mode 100644 index 00000000..44db367b --- /dev/null +++ b/devcon-api/data/sessions/devcon-7/securing-ethereum.json @@ -0,0 +1,26 @@ +{ + "id": "securing-ethereum", + "sourceId": "9FQPCQ", + "title": "Securing Ethereum", + "description": "l", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", + "type": "Panel", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "michael-lewellen", + "neville-grech", + "pietro-carta", + "michael-okeeffe" + ], + "eventId": "devcon-7", + "slot_start": 1731573000000, + "slot_end": 1731576300000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1m_-I_-ifsaORsMAY0_k78On1s9BICet-47EDiFzpEAM" +} \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/cls-eth-escape-speed-hacking-challenge.json b/devcon-api/data/sessions/devcon-7/speed-hacking-challenge.json similarity index 85% rename from devcon-api/data/sessions/devcon-7/cls-eth-escape-speed-hacking-challenge.json rename to devcon-api/data/sessions/devcon-7/speed-hacking-challenge.json index 650156da..75edfbd3 100644 --- a/devcon-api/data/sessions/devcon-7/cls-eth-escape-speed-hacking-challenge.json +++ b/devcon-api/data/sessions/devcon-7/speed-hacking-challenge.json @@ -1,9 +1,9 @@ { - "id": "cls-eth-escape-speed-hacking-challenge", + "id": "speed-hacking-challenge", "sourceId": "RSYU7K", - "title": "[CLS] ETH Escape - Speed Hacking Challenge", + "title": "Speed Hacking Challenge", "description": "​Prize Pool: $50,000\r\n\r\n​A High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t", - "track": "Entertainment", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", "type": "Mixed Formats", "expertise": "", "audience": "Engineering", diff --git a/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json b/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json index 72c68fbb..94bf49cd 100644 --- a/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json +++ b/devcon-api/data/sessions/devcon-7/the-history-and-philosophy-of-cypherpunk.json @@ -41,8 +41,8 @@ "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo", "resources_slides": null, "speakers": [ + "max-hampshire", "harry-halpin", - "iness-ben-guirat", - "max-hampshire" + "iness-ben-guirat" ] } \ No newline at end of file diff --git a/devcon-api/data/speakers/julian-sutherland.json b/devcon-api/data/speakers/julian-sutherland.json index a5d03389..69ef48fc 100644 --- a/devcon-api/data/speakers/julian-sutherland.json +++ b/devcon-api/data/speakers/julian-sutherland.json @@ -2,7 +2,7 @@ "id": "julian-sutherland", "sourceId": "J7BQQ3", "name": "Julian Sutherland", - "avatar": "https://speak.devcon.org/media/avatars/me_small_GvDXMvz.jpg", + "avatar": "https://speak.devcon.org/media/avatars/J7BQQ3_MGGo3pP.png", "description": "Julian leads the formal verification team at Nethermind, developing hard formal methods-based solutions to formally verifying the web3 ecosystem. Previously he completed his PhD at Imperial College on \"Compositional termination verification for fine-grained concurrency\" using separation logic.", "twitter": "juleksu", "github": "julek", diff --git a/devcon-api/data/speakers/michael-lewellen.json b/devcon-api/data/speakers/michael-lewellen.json new file mode 100644 index 00000000..45755fe4 --- /dev/null +++ b/devcon-api/data/speakers/michael-lewellen.json @@ -0,0 +1,10 @@ +{ + "id": "michael-lewellen", + "sourceId": "FAPSMV", + "name": "Michael Lewellen", + "avatar": "https://speak.devcon.org/media/avatars/tnd8gTR9_400x400_3_DAYCMcL.png", + "description": "Michael is the Head of Solutions Architecture at OpenZeppelin where he leads security advisory and security solutions for Ethereum protocols. He's been heavily involved in DAOs such as Compound and Arbitrum as a Security Advisor while contributing to community security initiatives such as the Security Alliance and EthTrust. Michael also teaches blockchain technology at UT Dallas and serves on the board of the Texas Blockchain Council.", + "twitter": "lewellenmichael", + "github": "cylon56", + "hash": "8ffde32718dd857aa87da21d2b9029025ac9698b1425391f634d65071976dbd3" +} \ No newline at end of file diff --git a/devcon-api/data/speakers/michael-okeeffe.json b/devcon-api/data/speakers/michael-okeeffe.json new file mode 100644 index 00000000..af1d0e50 --- /dev/null +++ b/devcon-api/data/speakers/michael-okeeffe.json @@ -0,0 +1,8 @@ +{ + "id": "michael-okeeffe", + "sourceId": "EF9SDL", + "name": "Michael O'Keeffe", + "avatar": "", + "description": "", + "hash": "85d035262246809ef4620a448c5b1882be39e27bf13ed64fff9ed4dc900bcfd6" +} \ No newline at end of file diff --git a/devcon-api/data/speakers/neville-grech.json b/devcon-api/data/speakers/neville-grech.json new file mode 100644 index 00000000..02b9e858 --- /dev/null +++ b/devcon-api/data/speakers/neville-grech.json @@ -0,0 +1,8 @@ +{ + "id": "neville-grech", + "sourceId": "BYSQXK", + "name": "Neville Grech", + "avatar": "https://speak.devcon.org/media/avatars/me4-cropped_G582DRy.jpg", + "description": "", + "hash": "e1badd85fc5a03cc3079ddb3b4a2c146937858e66674d7bcd17ceede2c08fa4c" +} \ No newline at end of file diff --git a/devcon-api/data/speakers/pietro-carta.json b/devcon-api/data/speakers/pietro-carta.json new file mode 100644 index 00000000..f1473368 --- /dev/null +++ b/devcon-api/data/speakers/pietro-carta.json @@ -0,0 +1,8 @@ +{ + "id": "pietro-carta", + "sourceId": "DME7EE", + "name": "Pietro Carta", + "avatar": "", + "description": "", + "hash": "a6fcecc55d8430b0cfb7ab133f8fdd7033ac1f6064c44dbcd6af7700adfdec3b" +} \ No newline at end of file diff --git a/devcon-api/data/speakers/vivian-chen.json b/devcon-api/data/speakers/vivian-chen.json index 032892e9..845e94a2 100644 --- a/devcon-api/data/speakers/vivian-chen.json +++ b/devcon-api/data/speakers/vivian-chen.json @@ -2,7 +2,7 @@ "id": "vivian-chen", "sourceId": "CJXMNA", "name": "Vivian Chen", - "avatar": "https://speak.devcon.org/media/avatars/Vivian_Chen_9AGSyGu1_ACMBJkG.jpg", + "avatar": "https://speak.devcon.org/media/avatars/CJXMNA_jLVaIAJ.png", "description": "Vivian Chen is a human rights activist who focuses on women's, children's, digital, and democratic rights. She was Taiwan's youth representative to the United Nations Commission on Status of Women and the official delegate to APEC. Since 2015, Vivian has worked with shelters for refugees, child laborers, orphans, and marginalized communities.\r\n\r\nVivian is the founding organizer of da0, a civic tech community in Taiwan, and the founding Catalyst of Pagoda, a network for Asian changemakers, contribu", "twitter": "vvntp6", "hash": "409e7f12da94d9a72d7defb15717db4cbb099ac6a70265ebb32e8bf583888c70" diff --git a/devcon-api/data/vectors/devcon-7.json b/devcon-api/data/vectors/devcon-7.json index 4dc5cdd3..7af19fec 100644 --- a/devcon-api/data/vectors/devcon-7.json +++ b/devcon-api/data/vectors/devcon-7.json @@ -27,7 +27,7 @@ ], "duration": 356, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "a3b09fc1d984db767d8af93657fd54b64f8af7c9391ada66823ed99d63801ffb", "sources_youtubeId": "PtYZgh6bYfE", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -783,6 +783,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -2691,6 +2692,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -3492,6 +3494,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -4854,6 +4857,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -6206,6 +6210,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -7583,6 +7588,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -8948,6 +8954,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -10278,6 +10285,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -11668,6 +11676,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -13029,6 +13038,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -14389,6 +14399,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -15726,6 +15737,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -17084,6 +17096,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -18476,6 +18489,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -19833,6 +19847,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -21176,6 +21191,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -22582,6 +22598,7 @@ 0, 0, 0, + 0, 2, 2, 0, @@ -23905,6 +23922,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -25230,6 +25248,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -26654,6 +26673,7 @@ 0, 0, 0, + 0, 2, 2, 0, @@ -28480,6 +28500,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -29823,6 +29844,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -30697,6 +30719,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -32036,6 +32059,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -32582,7 +32606,7 @@ ], "duration": 1465, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "16a3771bca4b5ce1a6ac65bcc81327d002a7cb59b050322799fee53af537ac03", "sources_youtubeId": "E6u3uQGP9J4", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -33351,6 +33375,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -33947,7 +33972,7 @@ ], "duration": 575, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "21ab9203390537d2ac46194c71f63c394cc6151c9464a574c67049bf8f07dcf3", "sources_youtubeId": "S3yf7c4GCbk", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -34716,6 +34741,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -35297,21 +35323,30 @@ "audience": "Business", "featured": false, "doNotRecord": false, - "keywords": [ - "startups" - ], "tags": [ "startup" ], - "language": "en", - "speakers": [ - "patricio-worthalter" + "keywords": [ + "startups" ], + "duration": 1597, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "Hp52dqbz3RU", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", "slot_start": 1731403800000, "slot_end": 1731405600000, "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1nL-c7JYqWnQddW0BtHR56cUv9hNYnZFOgm3Ce4DvdEQ" + "resources_presentation": "https://docs.google.com/presentation/d/1nL-c7JYqWnQddW0BtHR56cUv9hNYnZFOgm3Ce4DvdEQ", + "resources_slides": null, + "speakers": [ + "patricio-worthalter" + ] }, "vector": [ 0, @@ -36147,6 +36182,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -37502,6 +37538,7 @@ 0, 0, 0, + 0, 2, 2, 2, @@ -38789,6 +38826,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -40150,6 +40188,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -41566,6 +41605,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -42864,6 +42904,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -44219,6 +44260,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -45568,6 +45610,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -46991,6 +47034,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -48265,6 +48309,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -49616,6 +49661,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -51006,6 +51052,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -52313,6 +52360,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -53687,6 +53735,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -55038,6 +55087,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -56382,6 +56432,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -57748,6 +57799,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -59162,6 +59214,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -60563,6 +60616,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -61827,6 +61881,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -63269,6 +63324,7 @@ 0, 0, 0, + 0, 2, 2, 0, @@ -65067,6 +65123,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -65867,6 +65924,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -67302,6 +67360,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -68660,6 +68719,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -69961,6 +70021,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -71311,6 +71372,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -72673,6 +72735,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -74574,6 +74637,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -75388,6 +75452,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -76843,6 +76908,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -78171,6 +78237,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -78701,7 +78768,7 @@ ], "duration": 441, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "ce2604d6133c8452dee58f52c72413f9bf8be020ed9eeb8ffbf5bf634749c74c", "sources_youtubeId": "MbjUqblMpsY", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -79473,6 +79540,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -80067,7 +80135,7 @@ ], "duration": 558, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "4260dbd123f3448c32e94796b2c75769a70901b3a5bf4ec8e0eba1a04e20f4d0", "sources_youtubeId": "ul1D6N8qVJU", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -80839,6 +80907,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -82186,6 +82255,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -83562,6 +83632,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -84909,6 +84980,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -86263,6 +86335,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -87697,6 +87770,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -89051,6 +89125,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -90400,6 +90475,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -91760,6 +91836,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -93042,6 +93119,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -94481,6 +94559,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -95764,6 +95843,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -97114,6 +97194,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -98458,6 +98539,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -99863,6 +99945,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -101204,6 +101287,7 @@ 0, 0, 0, + 0, 2, 2, 0, @@ -102598,6 +102682,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -103889,6 +103974,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -105295,6 +105381,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -106615,6 +106702,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -107974,6 +108062,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -108569,7 +108658,7 @@ ], "duration": 464, "language": "en", - "sources_swarmHash": "", + "sources_swarmHash": "c40c5e3977516472e2a3c6acc41741648c8ab34684462e462f11d84b20326bea", "sources_youtubeId": "2og2d0Xxc3I", "sources_ipfsHash": "", "sources_livepeerId": "", @@ -109356,6 +109445,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -110741,6 +110831,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -112145,6 +112236,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -113418,6 +113510,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -114782,6 +114875,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -116126,6 +116220,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -117517,6 +117612,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -118939,6 +119035,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -120205,6 +120302,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -121631,6 +121729,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -122991,6 +123090,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -124246,6 +124346,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -125640,6 +125741,7 @@ 0, 0, 0, + 0, 2, 2, 0, @@ -126962,6 +127064,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -127530,36 +127633,31 @@ }, { "session": { - "id": "c-implementation-of-libp2p", - "sourceId": "F7UVJP", - "title": "C# implementation of Libp2p", - "description": "I’ll discuss the C# implementation of Nethermind's libp2p repository, where I implemented the TLS protocol, upgraded the Noise protocol, and added the Perf protocol. Although the first version of the C# implementation isn’t released yet, it is integrated with Gnosis Chain’s Shutter node.", + "id": "c-bindings-for-constantine-verkle-ipa", + "sourceId": "TDQFPX", + "title": "C bindings for Constantine verkle-ipa", + "description": "The session is part of final presentation of Ethereum Protocol Fellowship. In this talk I would be talking about the verkle-ipa provided by Constantine and exporting those to be made available for integration by clients for the verkle integration of ethereum roadmap.", "track": "[CLS] EPF Day", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Libp2p", - "Networking", - "P2P" - ], + "keywords": [], "tags": [ - "Consensus", - "Network State" + "Cryptography", + "Ethereum Roadmap", + "Verkle trees" ], "language": "en", "speakers": [ - "rose", - "richa", - "kira" + "richa" ], "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731476700000, + "slot_start": 1731473100000, + "slot_end": 1731474000000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/114N7ZFoxay5HlB8T-LpY8iCOTKX70658i91W43eXDpc" + "resources_presentation": "https://docs.google.com/presentation/d/10DqlfeLWBhwxvz53O8852FsvukCw9hOvBC9rvKdKNM8" }, "vector": [ 0, @@ -127720,8 +127818,6 @@ 0, 0, 6, - 6, - 6, 0, 0, 0, @@ -128305,7 +128401,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -128317,6 +128412,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -128347,7 +128443,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -128498,6 +128593,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -128884,34 +128983,36 @@ }, { "session": { - "id": "cafecosmos-mud-day-demo", - "sourceId": "FJLAMZ", - "title": "CafeCosmos - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nCafeCosmos is a fully onchain cafe building tycoon. Players are able to earn through redistributive DeFi contracts by speculating on the best earning recipes. \r\n\r\nBuild, Farm, Cook, Earn.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "c-implementation-of-libp2p", + "sourceId": "F7UVJP", + "title": "C# implementation of Libp2p", + "description": "I’ll discuss the C# implementation of Nethermind's libp2p repository, where I implemented the TLS protocol, upgraded the Noise protocol, and added the Perf protocol. Although the first version of the C# implementation isn’t released yet, it is integrated with Gnosis Chain’s Shutter node.", + "track": "[CLS] EPF Day", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Token Engineering", - "GameFi" + "Libp2p", + "Networking", + "P2P" ], "tags": [ - "Autonomous World", - "Gaming", - "Protocol Design" + "Consensus", + "Network State" ], "language": "en", "speakers": [ - "nico-rodriguez" + "rose", + "richa", + "kira" ], "eventId": "devcon-7", - "slot_start": 1731555600000, - "slot_end": 1731555900000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1PDrU1-lLeAQqLQ4AlBYvxRmDQ_iMUPXlUDleh2GhdJo" + "slot_start": 1731476700000, + "slot_end": 1731477600000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/114N7ZFoxay5HlB8T-LpY8iCOTKX70658i91W43eXDpc" }, "vector": [ 0, @@ -128926,11 +129027,10 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -129072,9 +129172,11 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -129657,6 +129759,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -129762,9 +129865,6 @@ 0, 0, 0, - 2, - 2, - 0, 0, 0, 0, @@ -130220,10 +130320,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -130236,46 +130338,38 @@ }, { "session": { - "id": "can-we-fix-mev", - "sourceId": "Z3BPXH", - "title": "Can we fix MEV?", - "description": "MEV is problematic today. The MEV supply chain puts centralizing pressure on Ethereum. There’s also an allocation problem; proposers (not apps or users) earn nearly all MEV, though they’re merely protocol agents. Numerous proposed solutions address this (ePBS, EAs, ETs, FOCIL, BRAID...), each with tradeoffs and assumptions about whether MEV is intrinsic to blockchains or extrinsic & preventable. Research is challenging to enter w/o continuous engagement. I’ll provide an overview of the research.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "cafecosmos-mud-day-demo", + "sourceId": "FJLAMZ", + "title": "CafeCosmos - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nCafeCosmos is a fully onchain cafe building tycoon. Players are able to earn through redistributive DeFi contracts by speculating on the best earning recipes. \r\n\r\nBuild, Farm, Cook, Earn.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Execution Tickets", - "Execution Auctions", - "BRAID" + "Token Engineering", + "GameFi" ], "tags": [ - "PBS", - "Consensus Mechanisms", - "MEV", - "execution", - "tickets", - "Consensus Mechanisms", - "MEV", - "PBS" + "Autonomous World", + "Gaming", + "Protocol Design" ], "language": "en", "speakers": [ - "jonah-burian" + "nico-rodriguez" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731646800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1uiCga8JgSVcEJbIHMSRcQYytS1nwlZiz6mLdidoUbr8" + "slot_start": 1731555600000, + "slot_end": 1731555900000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1PDrU1-lLeAQqLQ4AlBYvxRmDQ_iMUPXlUDleh2GhdJo" }, "vector": [ 0, 0, - 6, - 0, 0, 0, 0, @@ -130286,6 +130380,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -131012,7 +131107,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -131049,7 +131143,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -131060,6 +131153,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -131122,6 +131217,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -131204,9 +131302,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -131572,7 +131667,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -131584,6 +131678,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -131594,44 +131691,45 @@ }, { "session": { - "id": "can-we-formally-verify-implementations-of-cryptographic-libraries-like-the-c-kzg-library", - "sourceId": "HQP3RJ", - "title": "Can we formally verify implementations of cryptographic libraries like the c-kzg library?", - "description": "In this talk, we present our work on formally verifying the implementation of a cryptographic library key to the security of the Ethereum Data Availability layer: the c-kzg library. We will explore what we have been able to prove so far and what is ahead of us.", - "track": "Security", - "type": "Lightning Talk", + "id": "can-we-fix-mev", + "sourceId": "Z3BPXH", + "title": "Can we fix MEV?", + "description": "MEV is problematic today. The MEV supply chain puts centralizing pressure on Ethereum. There’s also an allocation problem; proposers (not apps or users) earn nearly all MEV, though they’re merely protocol agents. Numerous proposed solutions address this (ePBS, EAs, ETs, FOCIL, BRAID...), each with tradeoffs and assumptions about whether MEV is intrinsic to blockchains or extrinsic & preventable. Research is challenging to enter w/o continuous engagement. I’ll provide an overview of the research.", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Cryptol", - "SAW" + "Execution Tickets", + "Execution Auctions", + "BRAID" ], "tags": [ - "Layer 1", - "Cryptography", - "Formal Verification", - "saw", - "Cryptography", - "Formal Verification", - "Layer 1" + "PBS", + "Consensus Mechanisms", + "MEV", + "execution", + "tickets", + "Consensus Mechanisms", + "MEV", + "PBS" ], "language": "en", "speakers": [ - "thanh-hai-tran" + "jonah-burian" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731471000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1hG56xfpzqIZ6kxBtsd4z9tj3Nz-JQcrTh2y22jsemLo" + "slot_start": 1731645000000, + "slot_end": 1731646800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1uiCga8JgSVcEJbIHMSRcQYytS1nwlZiz6mLdidoUbr8" }, "vector": [ - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -132370,6 +132468,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -132379,9 +132479,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -132407,6 +132505,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -132564,7 +132663,8 @@ 0, 0, 2, - 0, + 2, + 2, 0, 0, 0, @@ -132932,8 +133032,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -132950,50 +133050,47 @@ }, { "session": { - "id": "can-zero-knowledge-and-blockchains-help-humanity-survive", - "sourceId": "ZCHNUF", - "title": "Can zero-knowledge and blockchains help humanity survive?", - "description": "While someone is building one more NFT marketplace rn... I claim that blockchains, privacy, and verifiability can disrupt, heal, and modify the world around us for real: spacetech, agrotech, biotech, AI/ML, neurotech, and many other domains have a fit for our beloved technology.\r\n\r\nBased on dozens of interviews with ppl from other industries, I want to share the most unexpected, exciting, and urgent use cases e.g. satellite coordination, post-nuclear war recovery, and LLMs presumption of innocence", - "track": "Real World Ethereum", + "id": "can-we-formally-verify-implementations-of-cryptographic-libraries-like-the-c-kzg-library", + "sourceId": "HQP3RJ", + "title": "Can we formally verify implementations of cryptographic libraries like the c-kzg library?", + "description": "In this talk, we present our work on formally verifying the implementation of a cryptographic library key to the security of the Ethereum Data Availability layer: the c-kzg library. We will explore what we have been able to prove so far and what is ahead of us.", + "track": "Security", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Developer", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Future of humanity", - "Ethereum prosperity", - "privacy-preserving blockchain" + "Cryptol", + "SAW" ], "tags": [ - "Zero-Knowledge", - "Use Cases", - "Product-market fit", - "privacy-preserving", - "blockchain", - "Product-market fit", - "Use Cases", - "Zero-Knowledge" + "Layer 1", + "Cryptography", + "Formal Verification", + "saw", + "Cryptography", + "Formal Verification", + "Layer 1" ], "language": "en", "speakers": [ - "lisa-akselrod" + "thanh-hai-tran" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731642000000, + "slot_start": 1731470400000, + "slot_end": 1731471000000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1lN3h53WUwFynoQ5vR7IcSTB74eoYrpCJWu2YVtIjyTw" + "resources_presentation": "https://docs.google.com/presentation/d/1hG56xfpzqIZ6kxBtsd4z9tj3Nz-JQcrTh2y22jsemLo" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -133736,10 +133833,13 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, + 6, + 0, 0, 0, 0, @@ -133782,7 +133882,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -133803,7 +133902,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -133922,10 +134020,9 @@ 0, 0, 0, - 2, - 2, 0, 0, + 2, 0, 0, 0, @@ -134303,44 +134400,47 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "chain-abstracted-smart-accounts-how-to-build-amazing-web3-ux-in-2024", - "sourceId": "E7QLZJ", - "title": "Chain-abstracted Smart Accounts -- How to Build Amazing Web3 UX in 2024", - "description": "Chain abstraction (CA) and account abstraction (AA) have been two of the hottest topics in Web3, but few people know how to use them together.\r\n\r\nIn this talk, I will explain how developers can build amazing Web3 experiences by combining AA with CA in the form of \"chain-abstracted smart accounts\" -- smart accounts that can spend their balances on any chain without bridging.", - "track": "Usability", + "id": "can-zero-knowledge-and-blockchains-help-humanity-survive", + "sourceId": "ZCHNUF", + "title": "Can zero-knowledge and blockchains help humanity survive?", + "description": "While someone is building one more NFT marketplace rn... I claim that blockchains, privacy, and verifiability can disrupt, heal, and modify the world around us for real: spacetech, agrotech, biotech, AI/ML, neurotech, and many other domains have a fit for our beloved technology.\r\n\r\nBased on dozens of interviews with ppl from other industries, I want to share the most unexpected, exciting, and urgent use cases e.g. satellite coordination, post-nuclear war recovery, and LLMs presumption of innocence", + "track": "Real World Ethereum", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Chain", - "Abstraction" + "Future of humanity", + "Ethereum prosperity", + "privacy-preserving blockchain" ], "tags": [ - "Cross-L2", - "User Experience", - "Account Abstraction", - "chain", - "abstraction", - "Account Abstraction", - "Cross-L2", - "User Experience" + "Zero-Knowledge", + "Use Cases", + "Product-market fit", + "privacy-preserving", + "blockchain", + "Product-market fit", + "Use Cases", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "derek-chiang" + "lisa-akselrod" ], "eventId": "devcon-7", - "slot_start": 1731553500000, - "slot_end": 1731554100000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1OMXnYKdkNqOzuJsNTBVLxJNmMzaz6upJphPKMzWFHU8" + "slot_start": 1731641400000, + "slot_end": 1731642000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1lN3h53WUwFynoQ5vR7IcSTB74eoYrpCJWu2YVtIjyTw" }, "vector": [ 0, @@ -134349,8 +134449,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -134507,6 +134605,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -135095,9 +135194,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -135132,7 +135231,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -135142,6 +135240,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -135161,6 +135261,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -135283,7 +135384,6 @@ 0, 2, 2, - 2, 0, 0, 0, @@ -135643,7 +135743,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -135651,6 +135750,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -135665,39 +135766,39 @@ }, { "session": { - "id": "chain-abstraction-but-i-want-to-know-where-my-tokens-are", - "sourceId": "SDMYAY", - "title": "Chain abstraction? But I want to know where my tokens are", - "description": "As a space, we face a big problem: how should we think about where assets live. Is Eth different from oEth or aEth. Does it matter where Circle prints your USDC? Should chains delegated to the kind of infra that Google Cloud or AWS is today? Clearly, the fragmentations of USDC/USDT/xDAI and then all the L2s creates horrible UX. However, the underlying assets are different things and the chains they live on have completely different security guarantees. Let's fix this!", + "id": "chain-abstracted-smart-accounts-how-to-build-amazing-web3-ux-in-2024", + "sourceId": "E7QLZJ", + "title": "Chain-abstracted Smart Accounts -- How to Build Amazing Web3 UX in 2024", + "description": "Chain abstraction (CA) and account abstraction (AA) have been two of the hottest topics in Web3, but few people know how to use them together.\r\n\r\nIn this talk, I will explain how developers can build amazing Web3 experiences by combining AA with CA in the form of \"chain-abstracted smart accounts\" -- smart accounts that can spend their balances on any chain without bridging.", "track": "Usability", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "UX", - "Chain abstraction" + "Chain", + "Abstraction" ], "tags": [ "Cross-L2", - "UI/UX", - "Accessibility", + "User Experience", + "Account Abstraction", "chain", "abstraction", - "Accessibility", + "Account Abstraction", "Cross-L2", - "UI/UX" + "User Experience" ], "language": "en", "speakers": [ - "konrad-urban" + "derek-chiang" ], "eventId": "devcon-7", - "slot_start": 1731556200000, - "slot_end": 1731556800000, + "slot_start": 1731553500000, + "slot_end": 1731554100000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1iiL0JiNnH0ChCkoh1IzT9f8BrqYd5kQugPQmJbbcZXo" + "resources_presentation": "https://docs.google.com/presentation/d/1OMXnYKdkNqOzuJsNTBVLxJNmMzaz6upJphPKMzWFHU8" }, "vector": [ 0, @@ -135864,7 +135965,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -136456,6 +136556,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -136488,6 +136591,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -136497,8 +136603,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -136998,17 +137102,15 @@ 0, 0, 0, - 0, - 0, 2, 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -137022,10 +137124,10 @@ }, { "session": { - "id": "chain-abstraction-is-risk-abstraction", - "sourceId": "E3XUE3", - "title": "Chain abstraction is risk abstraction", - "description": "The talk aims to provide a nuanced view of whether chain abstraction truly enhances user experience or introduces new layers of complexity and vulnerability. We'll explore the concept of chain abstraction, examine various approaches to it, and delve into the associated risks for users, as well as the strategies for mitigating these risks.", + "id": "chain-abstraction-but-i-want-to-know-where-my-tokens-are", + "sourceId": "SDMYAY", + "title": "Chain abstraction? But I want to know where my tokens are", + "description": "As a space, we face a big problem: how should we think about where assets live. Is Eth different from oEth or aEth. Does it matter where Circle prints your USDC? Should chains delegated to the kind of infra that Google Cloud or AWS is today? Clearly, the fragmentations of USDC/USDT/xDAI and then all the L2s creates horrible UX. However, the underlying assets are different things and the chains they live on have completely different security guarantees. Let's fix this!", "track": "Usability", "type": "Lightning Talk", "expertise": "Intermediate", @@ -137033,28 +137135,28 @@ "featured": false, "doNotRecord": false, "keywords": [ - "chain", - "abstraction" + "UX", + "Chain abstraction" ], "tags": [ "Cross-L2", - "Token bridging", - "Intents", + "UI/UX", + "Accessibility", "chain", "abstraction", + "Accessibility", "Cross-L2", - "Intents", - "Token bridging" + "UI/UX" ], "language": "en", "speakers": [ - "radina-talanova" + "konrad-urban" ], "eventId": "devcon-7", - "slot_start": 1731555600000, - "slot_end": 1731556200000, + "slot_start": 1731556200000, + "slot_end": 1731556800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1U-dbNKwiKAFUbasDggGI5sY4MPQrY0WG2flAU08jtEo" + "resources_presentation": "https://docs.google.com/presentation/d/1iiL0JiNnH0ChCkoh1IzT9f8BrqYd5kQugPQmJbbcZXo" }, "vector": [ 0, @@ -137222,7 +137324,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -137850,13 +137951,17 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -137998,8 +138103,6 @@ 2, 2, 2, - 2, - 0, 0, 0, 0, @@ -138379,39 +138482,39 @@ }, { "session": { - "id": "challenges-and-learnings-of-utilizing-blockchain-for-cash-assistance-in-wfpun", - "sourceId": "LCN8XD", - "title": "Challenges and learnings of utilizing blockchain for cash assistance in WFP/UN", - "description": "WFP has the largest blockchain projects focused on cash-based assistance: (a) It promotes a private EVM net since 2017 as a coordination mechanism to connect orgs providing humanitarian assistance (size: 4M ppl/month); (b) It is also scaling cash assistance in Afghanistan backed by public blockchain/100k people. \r\nCome to see some of our challenges and learnings of the last years consolidated in a model and engage to shape the future of this field.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", + "id": "chain-abstraction-is-risk-abstraction", + "sourceId": "E3XUE3", + "title": "Chain abstraction is risk abstraction", + "description": "The talk aims to provide a nuanced view of whether chain abstraction truly enhances user experience or introduces new layers of complexity and vulnerability. We'll explore the concept of chain abstraction, examine various approaches to it, and delve into the associated risks for users, as well as the strategies for mitigating these risks.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Product", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "humanitarian use cases", - "cash-based transfers" + "chain", + "abstraction" ], "tags": [ - "Best Practices", - "Emergency Plan", - "Ethereum for Good", - "transfer", - "cash", - "Best Practices", - "Emergency Plan", - "Ethereum for Good" + "Cross-L2", + "Token bridging", + "Intents", + "chain", + "abstraction", + "Cross-L2", + "Intents", + "Token bridging" ], "language": "en", "speakers": [ - "suzana-maranhao-moreno" + "radina-talanova" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1lKUWcEm1t3Bl4RRPCau4E1fatycz3c_Um37TvwammW4" + "slot_start": 1731555600000, + "slot_end": 1731556200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1U-dbNKwiKAFUbasDggGI5sY4MPQrY0WG2flAU08jtEo" }, "vector": [ 0, @@ -138420,9 +138523,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -138503,7 +138606,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -138581,6 +138683,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -139183,7 +139286,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -139209,6 +139311,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -139278,7 +139381,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -139359,7 +139461,7 @@ 2, 2, 2, - 0, + 2, 0, 0, 0, @@ -139722,6 +139824,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -139736,57 +139840,57 @@ }, { "session": { - "id": "challenges-developing-and-maintaining-open-source-software-in-web3", - "sourceId": "RT8WNR", - "title": "Challenges Developing and Maintaining Open Source Software in Web3", - "description": "Producing high-quality developer tools for the Web3 ecosystem is a challenging task that requires significant effort (and funding). Many of the best and most used tools started out as a lone hackers side-project, and then evolved into longer-standing projects by being absorbed into a larger companies efforts. In this talk, we'll share RV's open-source tool development story, and discuss what a better future could look like.", - "track": "Developer Experience", - "type": "Lightning Talk", + "id": "challenges-and-learnings-of-utilizing-blockchain-for-cash-assistance-in-wfpun", + "sourceId": "LCN8XD", + "title": "Challenges and learnings of utilizing blockchain for cash assistance in WFP/UN", + "description": "WFP has the largest blockchain projects focused on cash-based assistance: (a) It promotes a private EVM net since 2017 as a coordination mechanism to connect orgs providing humanitarian assistance (size: 4M ppl/month); (b) It is also scaling cash assistance in Afghanistan backed by public blockchain/100k people. \r\nCome to see some of our challenges and learnings of the last years consolidated in a model and engage to shape the future of this field.", + "track": "Real World Ethereum", + "type": "Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Product", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "tags": [ - "Tooling", - "Open Source Software", - "Public good", - "community", - "Open Source Software", - "Public good", - "Tooling" + "Best Practices", + "Emergency Plan", + "Ethereum for Good", + "transfer", + "cash", + "Best Practices", + "Emergency Plan", + "Ethereum for Good" ], "keywords": [ - "Grants", - "lessons", - "community" + "humanitarian use cases", + "cash-based transfers" ], - "duration": 545, + "duration": 1538, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "U93wI1oLKCA", + "sources_youtubeId": "TaaFxVq8IqU", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673322bf3a168eb535592a05.vtt", - "transcript_text": " Hi, I'm Everett Hildenbrandt, as was introduced, and I'm the CEO of Runtime Verification, and I'm here to talk to you about the challenges of developing open source software and maintaining it sustainably. Not necessarily in Web 3.0. It doesn't really matter, Web 3.0, Web 2.0. I mean, there's some different challenges in Web 3.0, but a lot of them end up being the same. So why are we qualified to talk about this at all? We have, you know, a huge GitHub presence, 170 public repositories, depending on how you count, 20, 12 to 37 of them are active at any given time. It's spanning 15 different programming languages, lots of external collaborators, obviously the internal developers at the team as well. You know, we have dependency chains within that software that run six deep in some cases, and we have different teams that range in size from one to ten. We've grown teams. We've shrank teams. We've, you know, done all sorts of different projects over the course of the last six years as I've been working at runtime verification. And we have super active and super awesome automation with CI and CD. So what are the challenges? I'm going to start from the easiest challenge to solve, which is the technical one. And a lot of people probably think, oh, this is the only challenge, the technical one. And, you know, with the technical challenge with managing open source software is automation. You need to automate everything. So you want to enforce as much as possible. We use GitHub for that. You can use GitLab or whatever other version control and publishing software you want to use. We use CI for testing. So every release is tested. That just keeps us sane, basically. Automated releases and updates. And so we actually have it. When we have those six dependency chains going on, six deep dependency chains, if there's an update to one of our pieces of software, it automatically pushes down the chain to the next piece of software for us. And one of the kind of challenges that you might notice is, you know, the software goes through different life cycles, right? When you first are developing a piece of software, you're in rapid development mode. You're prototyping. You're trying to move as quickly as possible, you don't want to be slowed down. And that looks a lot different than when you're in kind of the later stages of a project where you're just evolving the software over time, and you have a lot more tests there to guide you. So you need to accept that there are different life cycles to software development. And for example, keep GitHub enforcement turned off at the beginning of the development, and then, you know, a couple months in or a couple weeks in, turn on that GitHub enforcement. The second challenge is personnel, and this, maybe it even deserves to be the third challenge, because this is, you know, the medium difficulty challenge, but what I like to tell new hires at runtime verification is that learning to program is easy. Learning to program in a group is hard, right? And the key thing to remember is that you have to be respectful of other people's time, right? And, you know, one thing to keep in mind is it's always harder to read code than to write code. And so you're submitting code changes or something like that, and it was easy for you to read it because you have the intent in your mind and you translated it into code, it's much harder to go from that code and translate it back into the intent as the PR reviewer. So as the person who's authoring code, you need to make sure that your code is, you know, small changes, isolated changes, easy to read, well-tested, so that the PR reviewer has an easy time pressing the approve button. You know, remote work obviously makes this a lot harder. You know, when you're all in the same office together, you just turn around, hey, like, what do you think of this change? And you work on the same screen. But now we're talking about different time zones, and there's delays associated with that. So you have to keep all that in mind and actually keep it in your mental model for your development. And so here, process is key. Example, at runtime verification, I let everyone know, you know, beginning of your day, you clear your Slack messages first, then you do your pull request reviews, and then you do bulk code development on new code, and then you open new pull requests at the end of the day. You do your pull request reviews first because that's blocking someone, right? That is causing a synchronization point between you and someone else. They might be on the other side of the world, and suddenly, if you don't do that pull request review, you're delaying them by a day. And then that maybe delays you by a day. And so suddenly, you know, some small change gets delayed two days, maybe three days. If we're talking about an eight-week project and you have a handful of delays like that, you've lost two weeks on that eight-week project, right? That's not good. Anyway, next slide. The third challenge is money. And, you know, if you know how to solve this, please let me know. The solution I found is to beg. And, you know, the problem with begging is that everyone starts begging, and you need to have, like, a begging process and have a little structure to it. And so you have, like, grants and retrofunding and side quests where you get people to fund one thing, but then you develop another thing as well. And the problem with structured begging is that it becomes a game. And big players are better at games than small players. And so then the small players resort back to unstructured begging. And so, I don't know, we're back at square one. So anyway, that's my talk. You know, solve the technical challenges first. Prioritize those. That's the easiest part. Make sure as you onboard people that you make them aware of the personnel challenges, and then come let me know when you figure out the money thing. Thanks. Thank you. Any questions? Oh, there's one here. Great presentation. I just want to know more about runtime verification. I was checking the website, but it's much better for you to introduce what you do. Why are you working in open source? Yeah, so we do mostly formal verification and formal verification tooling. So we have this project called the K Framework. That's kind of our biggest project that is a tool that enables us to do formal verification for any programming language basically And so we have formal verification tools for solidity for web assembly for rust We also have for some other blockchain like Cardano and Tezos and stuff like that so that require That's a big formal verification is hard software to develop, and it's used in a bunch of other contexts as well. And so we just end up having a lot of different repositories targeting different ecosystems and different programming languages that we do and most of that is done for security audits, basically. So. Thank you. There's a question over there. Thanks. Hi. Because you already mentioned the workflow, especially the GitHub pull requests, so I had a question about that. Do you have any advice in terms of leading the team and structuring the PR reviews? Because in my opinion, when there is an update or is a bug fix, it's quite straightforward. It doesn't really matter the number of commits, because you look at the change, you look at the description, you know kind of what's happening. But perhaps you have an advice on how to structure the commits when it comes to a new change. And when you said about like the method, like it's hard to construct the intent by looking at the changes. So perhaps having more commits and following them one by one would help with that? Or you know what I'm asking? Yeah, yeah. Perhaps have it up there. I mean, it's challenging and it's challenging not because it's a non-solve problem. It's challenging because people just don't do it, right? But I mean, have good commit hygiene. Try to make it so, I try to make it so every commit builds, if not passing tests. It might be that you're going through refactoring and tests have to be failing in the middle there, but every commit should build, in my opinion. And so that should make it so every commit you can review in isolation if that's necessary, which is not the ideal way to do it because that takes a little longer to review. But then the second piece of advice I'd give on that is, as a pull request reviewer, just be really picky. You know, if someone sends you a pull request that is changing four different things and it's hard to review the whole thing and keep it all in your head, don't bother reviewing it. Just send it back to them and say, hey, you weren't respectful of my time. Break this into four pull requests and I'll review each one independently. Because ideally, as a pull request reviewer, it's easy for you to look at a pull request and say, this is a good change. I'm going to hit approve and move on, right? But if you can't do that, and you have to now dissect what is this change doing, you're not the expert on it. You didn't write that code. It's much easier for the person who authored the pull request to go and split that up into multiple different pull requests than it is for you to dissect what they meant, right? So don't, as a pull request reviewer, don't be shy. Just be like, look, be more respectful of my time, please. Go break this up into multiple pull requests so I can review each independently. That's my opinion on it. All right. Thank you very much. Thanks. Thanks for the tips for PR reviews.", + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731403200000, - "slot_end": 1731403800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1qjEbqOegs1ocDdXvx_djLjbOkH762J5kzikQ4VqSqdg", + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1lKUWcEm1t3Bl4RRPCau4E1fatycz3c_Um37TvwammW4", "resources_slides": null, "speakers": [ - "everett-hildenbrandt" + "suzana-maranhao-moreno" ] }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -139869,6 +139973,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -139947,7 +140052,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -140539,7 +140643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -140551,6 +140654,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -140616,7 +140720,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -140627,7 +140730,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -140647,6 +140749,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -140694,7 +140797,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -140727,6 +140829,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -141086,9 +141191,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -141102,47 +141207,53 @@ }, { "session": { - "id": "changes-to-the-l1-evm-versus-l2s", - "sourceId": "MFYXWT", - "title": "Changes to the L1 EVM versus L2s", - "description": "The EVM has long been a target for improvement, but major changes have been postponed due to other priorities. As Ethereum's core, EVM modifications could significantly affect network stability, security, and performance, or add complexity. This necessitates lengthy approval and implementation processes. Panelists will explore new initiatives to implement EVM upgrades such as the EOF on L2s before L1, discussing their pros and cons.", - "track": "Core Protocol", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "challenges-developing-and-maintaining-open-source-software-in-web3", + "sourceId": "RT8WNR", + "title": "Challenges Developing and Maintaining Open Source Software in Web3", + "description": "Producing high-quality developer tools for the Web3 ecosystem is a challenging task that requires significant effort (and funding). Many of the best and most used tools started out as a lone hackers side-project, and then evolved into longer-standing projects by being absorbed into a larger companies efforts. In this talk, we'll share RV's open-source tool development story, and discuss what a better future could look like.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [ - "EVM" - ], "tags": [ - "Core Protocol", - "Layer 2s", - "Governance", - "EVM", - "Core Protocol", - "Governance", - "Layer 2s" + "Tooling", + "Open Source Software", + "Public good", + "community", + "Open Source Software", + "Public good", + "Tooling" ], - "language": "en", - "speakers": [ - "lightclient", - "alex-beregszaszi", - "daniel", - "eniko-garam", - "mark-tyneway" + "keywords": [ + "Grants", + "lessons", + "community" ], + "duration": 545, + "language": "en", + "sources_swarmHash": "25e6ed887207dbca41799d009fc12cdef9f1b8e73205686de952a3102690d3fe", + "sources_youtubeId": "U93wI1oLKCA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673322bf3a168eb535592a05.vtt", + "transcript_text": " Hi, I'm Everett Hildenbrandt, as was introduced, and I'm the CEO of Runtime Verification, and I'm here to talk to you about the challenges of developing open source software and maintaining it sustainably. Not necessarily in Web 3.0. It doesn't really matter, Web 3.0, Web 2.0. I mean, there's some different challenges in Web 3.0, but a lot of them end up being the same. So why are we qualified to talk about this at all? We have, you know, a huge GitHub presence, 170 public repositories, depending on how you count, 20, 12 to 37 of them are active at any given time. It's spanning 15 different programming languages, lots of external collaborators, obviously the internal developers at the team as well. You know, we have dependency chains within that software that run six deep in some cases, and we have different teams that range in size from one to ten. We've grown teams. We've shrank teams. We've, you know, done all sorts of different projects over the course of the last six years as I've been working at runtime verification. And we have super active and super awesome automation with CI and CD. So what are the challenges? I'm going to start from the easiest challenge to solve, which is the technical one. And a lot of people probably think, oh, this is the only challenge, the technical one. And, you know, with the technical challenge with managing open source software is automation. You need to automate everything. So you want to enforce as much as possible. We use GitHub for that. You can use GitLab or whatever other version control and publishing software you want to use. We use CI for testing. So every release is tested. That just keeps us sane, basically. Automated releases and updates. And so we actually have it. When we have those six dependency chains going on, six deep dependency chains, if there's an update to one of our pieces of software, it automatically pushes down the chain to the next piece of software for us. And one of the kind of challenges that you might notice is, you know, the software goes through different life cycles, right? When you first are developing a piece of software, you're in rapid development mode. You're prototyping. You're trying to move as quickly as possible, you don't want to be slowed down. And that looks a lot different than when you're in kind of the later stages of a project where you're just evolving the software over time, and you have a lot more tests there to guide you. So you need to accept that there are different life cycles to software development. And for example, keep GitHub enforcement turned off at the beginning of the development, and then, you know, a couple months in or a couple weeks in, turn on that GitHub enforcement. The second challenge is personnel, and this, maybe it even deserves to be the third challenge, because this is, you know, the medium difficulty challenge, but what I like to tell new hires at runtime verification is that learning to program is easy. Learning to program in a group is hard, right? And the key thing to remember is that you have to be respectful of other people's time, right? And, you know, one thing to keep in mind is it's always harder to read code than to write code. And so you're submitting code changes or something like that, and it was easy for you to read it because you have the intent in your mind and you translated it into code, it's much harder to go from that code and translate it back into the intent as the PR reviewer. So as the person who's authoring code, you need to make sure that your code is, you know, small changes, isolated changes, easy to read, well-tested, so that the PR reviewer has an easy time pressing the approve button. You know, remote work obviously makes this a lot harder. You know, when you're all in the same office together, you just turn around, hey, like, what do you think of this change? And you work on the same screen. But now we're talking about different time zones, and there's delays associated with that. So you have to keep all that in mind and actually keep it in your mental model for your development. And so here, process is key. Example, at runtime verification, I let everyone know, you know, beginning of your day, you clear your Slack messages first, then you do your pull request reviews, and then you do bulk code development on new code, and then you open new pull requests at the end of the day. You do your pull request reviews first because that's blocking someone, right? That is causing a synchronization point between you and someone else. They might be on the other side of the world, and suddenly, if you don't do that pull request review, you're delaying them by a day. And then that maybe delays you by a day. And so suddenly, you know, some small change gets delayed two days, maybe three days. If we're talking about an eight-week project and you have a handful of delays like that, you've lost two weeks on that eight-week project, right? That's not good. Anyway, next slide. The third challenge is money. And, you know, if you know how to solve this, please let me know. The solution I found is to beg. And, you know, the problem with begging is that everyone starts begging, and you need to have, like, a begging process and have a little structure to it. And so you have, like, grants and retrofunding and side quests where you get people to fund one thing, but then you develop another thing as well. And the problem with structured begging is that it becomes a game. And big players are better at games than small players. And so then the small players resort back to unstructured begging. And so, I don't know, we're back at square one. So anyway, that's my talk. You know, solve the technical challenges first. Prioritize those. That's the easiest part. Make sure as you onboard people that you make them aware of the personnel challenges, and then come let me know when you figure out the money thing. Thanks. Thank you. Any questions? Oh, there's one here. Great presentation. I just want to know more about runtime verification. I was checking the website, but it's much better for you to introduce what you do. Why are you working in open source? Yeah, so we do mostly formal verification and formal verification tooling. So we have this project called the K Framework. That's kind of our biggest project that is a tool that enables us to do formal verification for any programming language basically And so we have formal verification tools for solidity for web assembly for rust We also have for some other blockchain like Cardano and Tezos and stuff like that so that require That's a big formal verification is hard software to develop, and it's used in a bunch of other contexts as well. And so we just end up having a lot of different repositories targeting different ecosystems and different programming languages that we do and most of that is done for security audits, basically. So. Thank you. There's a question over there. Thanks. Hi. Because you already mentioned the workflow, especially the GitHub pull requests, so I had a question about that. Do you have any advice in terms of leading the team and structuring the PR reviews? Because in my opinion, when there is an update or is a bug fix, it's quite straightforward. It doesn't really matter the number of commits, because you look at the change, you look at the description, you know kind of what's happening. But perhaps you have an advice on how to structure the commits when it comes to a new change. And when you said about like the method, like it's hard to construct the intent by looking at the changes. So perhaps having more commits and following them one by one would help with that? Or you know what I'm asking? Yeah, yeah. Perhaps have it up there. I mean, it's challenging and it's challenging not because it's a non-solve problem. It's challenging because people just don't do it, right? But I mean, have good commit hygiene. Try to make it so, I try to make it so every commit builds, if not passing tests. It might be that you're going through refactoring and tests have to be failing in the middle there, but every commit should build, in my opinion. And so that should make it so every commit you can review in isolation if that's necessary, which is not the ideal way to do it because that takes a little longer to review. But then the second piece of advice I'd give on that is, as a pull request reviewer, just be really picky. You know, if someone sends you a pull request that is changing four different things and it's hard to review the whole thing and keep it all in your head, don't bother reviewing it. Just send it back to them and say, hey, you weren't respectful of my time. Break this into four pull requests and I'll review each one independently. Because ideally, as a pull request reviewer, it's easy for you to look at a pull request and say, this is a good change. I'm going to hit approve and move on, right? But if you can't do that, and you have to now dissect what is this change doing, you're not the expert on it. You didn't write that code. It's much easier for the person who authored the pull request to go and split that up into multiple different pull requests than it is for you to dissect what they meant, right? So don't, as a pull request reviewer, don't be shy. Just be like, look, be more respectful of my time, please. Go break this up into multiple pull requests so I can review each independently. That's my opinion on it. All right. Thank you very much. Thanks. Thanks for the tips for PR reviews.", "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731573000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Vhj4BZKZxNH74CAaa0TGW6GQk3bGkBt7tTxzfTfY5O0" + "slot_start": 1731403200000, + "slot_end": 1731403800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1qjEbqOegs1ocDdXvx_djLjbOkH762J5kzikQ4VqSqdg", + "resources_slides": null, + "speakers": [ + "everett-hildenbrandt" + ] }, "vector": [ 0, 0, 0, - 0, 6, 0, 0, @@ -141308,10 +141419,6 @@ 0, 0, 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -141896,7 +142003,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -141905,6 +142011,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -141943,7 +142053,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -141973,13 +142082,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -141990,6 +142099,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -142056,6 +142166,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -142084,7 +142197,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -142439,7 +142551,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -142447,6 +142558,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -142461,49 +142574,48 @@ }, { "session": { - "id": "cheatcalls-eip", - "sourceId": "FSSDUT", - "title": "Cheatcalls EIP", - "description": "Development nodes, such as Anvil, Hardhat, and Tenderly, provide specialized methods to manipulate blockchain state. For example, the `anvil_setCode` method allows arbitrary overriding smart contract code. \r\n\r\nUnfortunately, each node implements a slightly different set of methods with varying behaviours, resulting in wasted development hours and potential vendor lock-in.\r\n\r\nIn my talk, I introduce a new EIP that proposes standardized `cheat_*` methods with well-defined interfaces and behaviour.", - "track": "Developer Experience", - "type": "Talk", + "id": "changes-to-the-l1-evm-versus-l2s", + "sourceId": "MFYXWT", + "title": "Changes to the L1 EVM versus L2s", + "description": "The EVM has long been a target for improvement, but major changes have been postponed due to other priorities. As Ethereum's core, EVM modifications could significantly affect network stability, security, and performance, or add complexity. This necessitates lengthy approval and implementation processes. Panelists will explore new initiatives to implement EVM upgrades such as the EOF on L2s before L1, discussing their pros and cons.", + "track": "Core Protocol", + "type": "Panel", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "EIP", - "anvil", - "hardhat" + "EVM" ], "tags": [ - "Developer Infrastructure", - "DevEx", - "Best Practices", - "hardhat", - "Best Practices", - "Developer Infrastructure", - "DevEx" + "Core Protocol", + "Layer 2s", + "Governance", + "EVM", + "Core Protocol", + "Governance", + "Layer 2s" ], "language": "en", "speakers": [ - "kris-kaczor" + "lightclient", + "alex-beregszaszi", + "daniel", + "eniko-garam", + "mark-tyneway" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, + "slot_start": 1731569400000, + "slot_end": 1731573000000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1SPNfEMjAph1OpaPequc8om3JZMEGtbmn17fCEmGQhuE" + "resources_presentation": "https://docs.google.com/presentation/d/1Vhj4BZKZxNH74CAaa0TGW6GQk3bGkBt7tTxzfTfY5O0" }, "vector": [ - 0, - 0, - 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -142667,9 +142779,13 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -143253,6 +143369,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -143264,8 +143381,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -143288,7 +143403,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -143302,6 +143416,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -143331,6 +143446,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -143442,8 +143558,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -143818,42 +143934,39 @@ }, { "session": { - "id": "check-your-users-humanity-nationality-or-age-with-privacy-preserving-id-proofs", - "sourceId": "XUUMW3", - "title": "Check your user's humanity, nationality or age with privacy-preserving ID proofs!", - "description": "This workshop shows how to use the Proof of Passport SDK to check user's identity in a few lines of code. Let users generate zk proofs of age, nationality, humanity or non-inclusion in the OFAC list by scanning the NFC chip in their passport or ID card, and without ever having to reveal any private information.\r\n\r\nCome try it now!", + "id": "cheatcalls-eip", + "sourceId": "FSSDUT", + "title": "Cheatcalls EIP", + "description": "Development nodes, such as Anvil, Hardhat, and Tenderly, provide specialized methods to manipulate blockchain state. For example, the `anvil_setCode` method allows arbitrary overriding smart contract code. \r\n\r\nUnfortunately, each node implements a slightly different set of methods with varying behaviours, resulting in wasted development hours and potential vendor lock-in.\r\n\r\nIn my talk, I introduce a new EIP that proposes standardized `cheat_*` methods with well-defined interfaces and behaviour.", "track": "Developer Experience", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Product", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Social media", - "airdrop", - "compliance" + "EIP", + "anvil", + "hardhat" ], "tags": [ - "Tooling", - "Quadratic Voting", - "Identity", - "compliance", - "Identity", - "Quadratic Voting", - "Tooling" + "Developer Infrastructure", + "DevEx", + "Best Practices", + "hardhat", + "Best Practices", + "Developer Infrastructure", + "DevEx" ], "language": "en", "speakers": [ - "michael-elliot", - "florent", - "remi", - "theo-madzou" + "kris-kaczor" ], "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731565800000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/116i9aeE05txm_kkq2IUV5e1zkt4cdfE8v3unnfsygbQ" + "slot_start": 1731493800000, + "slot_end": 1731495600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1SPNfEMjAph1OpaPequc8om3JZMEGtbmn17fCEmGQhuE" }, "vector": [ 0, @@ -144029,10 +144142,6 @@ 0, 0, 0, - 0, - 6, - 6, - 6, 6, 0, 0, @@ -144615,7 +144724,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -144630,6 +144738,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -144643,7 +144753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -144653,6 +144762,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -144803,12 +144914,11 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -145158,9 +145268,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -145173,38 +145283,53 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "circle-for-all", - "sourceId": "VPNPYY", - "title": "Circle for all", - "description": "By master Aoei\r\n- Self-Tune\r\n- Circle movement bonding activities\r\n- Sharing and Reflecting\r\n\r\nNov 13 15:00 - 15:45", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", + "id": "check-your-users-humanity-nationality-or-age-with-privacy-preserving-id-proofs", + "sourceId": "XUUMW3", + "title": "Check your user's humanity, nationality or age with privacy-preserving ID proofs!", + "description": "This workshop shows how to use the Proof of Passport SDK to check user's identity in a few lines of code. Let users generate zk proofs of age, nationality, humanity or non-inclusion in the OFAC list by scanning the NFC chip in their passport or ID card, and without ever having to reveal any private information.\r\n\r\nCome try it now!", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Social media", + "airdrop", + "compliance" + ], + "tags": [ + "Tooling", + "Quadratic Voting", + "Identity", + "compliance", + "Identity", + "Quadratic Voting", + "Tooling" + ], "language": "en", - "speakers": [], + "speakers": [ + "michael-elliot", + "florent", + "remi", + "theo-madzou" + ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731487500000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1hrC4BF-BEAqbZu7xLGF7HSCIT40WN7UKvfkGD14lwho" + "slot_start": 1731560400000, + "slot_end": 1731565800000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/116i9aeE05txm_kkq2IUV5e1zkt4cdfE8v3unnfsygbQ" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -145379,6 +145504,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -145961,6 +146090,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -145988,6 +146118,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -146149,6 +146280,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -146503,11 +146636,10 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -146521,40 +146653,25 @@ }, { "session": { - "id": "circle-stark-gpu-acceleration-an-analysis-of-performance-and-implementation", - "sourceId": "MUG9QP", - "title": "Circle STARK GPU Acceleration: An Analysis of Performance and Implementation", - "description": "The session will cover the overview of GPU acceleration for ZK-SNARK/STARK proof systems, focusing on the GPU implementation of Circle STARK. It will address challenges and solutions in implementation, delving into parallelizing computations in provers. We'll compare CPU and GPU performance. Finally, we'll explore future directions for hardware acceleration (ie. FPGA).", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Beginner", + "id": "circle-for-all", + "sourceId": "VPNPYY", + "title": "Circle for all", + "description": "By master Aoei\r\n- Self-Tune\r\n- Circle movement bonding activities\r\n- Sharing and Reflecting\r\n\r\nNov 13 15:00 - 15:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Circle STARK", - "Stwo", - "GPU" - ], - "tags": [ - "ZKP", - "Zero-Knowledge", - "STARK", - "gpu", - "STARK", - "Zero-Knowledge", - "ZKP" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "daniel", - "julian-arnesino" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1P0tuKkaODBsM7KxkSGtcEnPO4Ol_WaMBik4Mne_Fr0Y" + "slot_start": 1731484800000, + "slot_end": 1731487500000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1hrC4BF-BEAqbZu7xLGF7HSCIT40WN7UKvfkGD14lwho" }, "vector": [ 0, @@ -146566,7 +146683,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -146727,7 +146843,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -146735,7 +146850,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -147307,7 +147421,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -147370,7 +147483,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -147506,8 +147618,13 @@ 0, 0, 0, - 2, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -147861,6 +147978,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -147879,38 +147997,43 @@ }, { "session": { - "id": "circles-resilient-money", - "sourceId": "EWTZTD", - "title": "Circles - resilient money", - "description": "Circles is an attempt to design money while maximizing decentralization and resilience. Furthermore it tries to find a balance between \"newcomers\", joining the social contract that any form of money represents, and those already in it.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "id": "circle-stark-gpu-acceleration-an-analysis-of-performance-and-implementation", + "sourceId": "MUG9QP", + "title": "Circle STARK GPU Acceleration: An Analysis of Performance and Implementation", + "description": "The session will cover the overview of GPU acceleration for ZK-SNARK/STARK proof systems, focusing on the GPU implementation of Circle STARK. It will address challenges and solutions in implementation, delving into parallelizing computations in provers. We'll compare CPU and GPU performance. Finally, we'll explore future directions for hardware acceleration (ie. FPGA).", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "fair", - "money" + "Circle STARK", + "Stwo", + "GPU" ], "tags": [ - "macro/micro economics", - "Public good", - "Solarpunk" + "ZKP", + "Zero-Knowledge", + "STARK", + "gpu", + "STARK", + "Zero-Knowledge", + "ZKP" ], "language": "en", "speakers": [ - "koeppelmann" + "daniel", + "julian-arnesino" ], "eventId": "devcon-7", - "slot_start": 1731558480000, - "slot_end": 1731559320000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1M-GH6csygqzvZdnn2OpNm0N7Qq6jQ2Z9bbEUeyCxiOY" + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1P0tuKkaODBsM7KxkSGtcEnPO4Ol_WaMBik4Mne_Fr0Y" }, "vector": [ 0, - 6, 0, 0, 0, @@ -147920,6 +148043,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -148079,6 +148203,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -148086,9 +148211,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -148659,6 +148784,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -148718,6 +148847,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -148756,9 +148889,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -148772,11 +148902,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -148861,6 +148986,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -149209,16 +149335,15 @@ 0, 0, 0, - 2, - 0, 0, + 2, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -149231,42 +149356,38 @@ }, { "session": { - "id": "circom-buses-a-new-journey", - "sourceId": "C7T3QL", - "title": "Circom buses: a new journey", - "description": "Circom is one of the most widely used languages in programmable cryptography. In this talk we present an amazing new circom feature, called buses. Like structs in other languages, programmers can define their own buses, as new types, in a general way to create structured collections of signals and freely use them in their code. Buses increase the readability, modularity and security of circuits. Illustrative examples as well as the renewed circomlib, using buses, are presented.", - "track": "Applied Cryptography", - "type": "Talk", + "id": "circles-resilient-money", + "sourceId": "EWTZTD", + "title": "Circles - resilient money", + "description": "Circles is an attempt to design money while maximizing decentralization and resilience. Furthermore it tries to find a balance between \"newcomers\", joining the social contract that any form of money represents, and those already in it.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Programmable Cryptography", - "circom", - "buses" + "fair", + "money" ], "tags": [ - "ZKP", - "Zero-Knowledge", - "Cryptography", - "buses", - "Cryptography", - "Zero-Knowledge", - "ZKP" + "macro/micro economics", + "Public good", + "Solarpunk" ], "language": "en", "speakers": [ - "albert-rubio" + "koeppelmann" ], "eventId": "devcon-7", - "slot_start": 1731658200000, - "slot_end": 1731659400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1noOR17_aYCG_ZJUZyMBpdklsW49xHNFwO6ykyh99eko" + "slot_start": 1731558480000, + "slot_end": 1731559320000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1M-GH6csygqzvZdnn2OpNm0N7Qq6jQ2Z9bbEUeyCxiOY" }, "vector": [ 0, + 6, 0, 0, 0, @@ -149276,8 +149397,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -150016,8 +150135,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -150079,7 +150196,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -150118,6 +150234,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -150131,6 +150250,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -150218,9 +150338,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -150572,10 +150693,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -150588,38 +150709,39 @@ }, { "session": { - "id": "civic-tech-meets-dao-lessons-from-japans-largest-digital-public-goods-community", - "sourceId": "G7CUCX", - "title": "Civic Tech Meets DAO: Lessons from Japan's Largest Digital Public Goods Community", - "description": "Code for Japan, Japan's largest civic tech community, is implementing DAO concepts and Ethereum coordination mechanisms to enhance its decentralized structure and sustain open-source projects. This talk explores our journey in applying on-chain governance to an established volunteer-based community, highlighting our approaches to contribution visualization and project support using NFTs and QF. We'll share key challenges, solutions, and learnings from bridging web2 and web3 in civic tech.", - "track": "Coordination", + "id": "circom-buses-a-new-journey", + "sourceId": "C7T3QL", + "title": "Circom buses: a new journey", + "description": "Circom is one of the most widely used languages in programmable cryptography. In this talk we present an amazing new circom feature, called buses. Like structs in other languages, programmers can define their own buses, as new types, in a general way to create structured collections of signals and freely use them in their code. Buses increase the readability, modularity and security of circuits. Illustrative examples as well as the renewed circomlib, using buses, are presented.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "civic tech", - "Plurality" + "Programmable Cryptography", + "circom", + "buses" ], "tags": [ - "DAO", - "Quadratic Voting", - "Public good", - "plurality", - "DAO", - "Public good", - "Quadratic Voting" + "ZKP", + "Zero-Knowledge", + "Cryptography", + "buses", + "Cryptography", + "Zero-Knowledge", + "ZKP" ], "language": "en", "speakers": [ - "hal-seki" + "albert-rubio" ], "eventId": "devcon-7", - "slot_start": 1731496200000, - "slot_end": 1731498000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1HA7lnd6KnPUYw130uBGO9g_dh4nt0Km9EV8l4rT8-rU" + "slot_start": 1731658200000, + "slot_end": 1731659400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1noOR17_aYCG_ZJUZyMBpdklsW49xHNFwO6ykyh99eko" }, "vector": [ 0, @@ -150632,7 +150754,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -151374,6 +151495,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -151435,6 +151558,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -151461,7 +151585,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -151469,7 +151592,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -151569,16 +151691,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -151930,7 +152051,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -151939,50 +152059,48 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "clear-a-formal-verification-framework-for-smart-contracts-in-lean", - "sourceId": "M3QKTW", - "title": "Clear: a Formal Verification framework for smart contracts in Lean", - "description": "Join us for an in-depth workshop on the Clear framework, a cutting-edge tool designed for the formal verification of smart contracts by extracting Yul code into Lean. This workshop will explore Clear’s remarkable expressivity, enabling any pen-and-paper proof of correctness to be mechanized in Lean. Participants will learn about Clear's compositionality and abstraction, allowing scalable verification of complex smart-contracts, and its automation capabilities to streamline proof generation.", - "track": "Security", - "type": "Workshop", - "expertise": "Expert", - "audience": "Engineering", + "id": "civic-tech-meets-dao-lessons-from-japans-largest-digital-public-goods-community", + "sourceId": "G7CUCX", + "title": "Civic Tech Meets DAO: Lessons from Japan's Largest Digital Public Goods Community", + "description": "Code for Japan, Japan's largest civic tech community, is implementing DAO concepts and Ethereum coordination mechanisms to enhance its decentralized structure and sustain open-source projects. This talk explores our journey in applying on-chain governance to an established volunteer-based community, highlighting our approaches to contribution visualization and project support using NFTs and QF. We'll share key challenges, solutions, and learnings from bridging web2 and web3 in civic tech.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Yul", - "Lean", - "ITP" + "civic tech", + "Plurality" ], "tags": [ - "Frameworks", - "Security", - "Formal Verification", - "yul", - "lean", - "itp", - "Formal Verification", - "Frameworks", - "Security" + "DAO", + "Quadratic Voting", + "Public good", + "plurality", + "DAO", + "Public good", + "Quadratic Voting" ], "language": "en", "speakers": [ - "julian-sutherland" + "hal-seki" ], "eventId": "devcon-7", - "slot_start": 1731471600000, - "slot_end": 1731477000000, + "slot_start": 1731496200000, + "slot_end": 1731498000000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1J21ogENKuo-BCOrzHLQIUHr3yr7F7Ki9YBkOmnf6sTU" + "resources_presentation": "https://docs.google.com/presentation/d/1HA7lnd6KnPUYw130uBGO9g_dh4nt0Km9EV8l4rT8-rU" }, "vector": [ - 6, - 0, 0, 0, 0, @@ -151994,6 +152112,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -152719,8 +152838,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -152832,6 +152949,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -152916,8 +153034,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -152936,7 +153052,11 @@ 0, 0, 2, - 2, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -153285,13 +153405,14 @@ 0, 0, 2, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -153303,45 +153424,43 @@ }, { "session": { - "id": "clookup-composite-function-based-lookup-argument", - "sourceId": "TJ9TMF", - "title": "Clookup - Composite Function based Lookup Argument", - "description": "Presenting Clookup, a novel lookup protocol that enhances efficiency in verifiable computations. By using a composite function approach and multivariate polynomials within the sumcheck protocol, Clookup achieves optimal time complexity \\(O(m(m+n))\\) when processing \\(2^m\\) witness elements against a \\(2^n\\) table. This method eliminates the need to compute coefficient forms of composite functions.", - "track": "Applied Cryptography", - "type": "Talk", + "id": "clear-a-formal-verification-framework-for-smart-contracts-in-lean", + "sourceId": "M3QKTW", + "title": "Clear: a Formal Verification framework for smart contracts in Lean", + "description": "Join us for an in-depth workshop on the Clear framework, a cutting-edge tool designed for the formal verification of smart contracts by extracting Yul code into Lean. This workshop will explore Clear’s remarkable expressivity, enabling any pen-and-paper proof of correctness to be mechanized in Lean. Participants will learn about Clear's compositionality and abstraction, allowing scalable verification of complex smart-contracts, and its automation capabilities to streamline proof generation.", + "track": "Security", + "type": "Workshop", "expertise": "Expert", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Lookup", - "Arguments" + "Yul", + "Lean", + "ITP" ], "tags": [ - "Cryptography", - "ZKP" + "Frameworks", + "Security", + "Formal Verification", + "yul", + "lean", + "itp", + "Formal Verification", + "Frameworks", + "Security" ], "language": "en", "speakers": [ - "wanseob-lim" + "julian-sutherland" ], "eventId": "devcon-7", - "slot_start": 1731659400000, - "slot_end": 1731660600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1N-AwhGffiR0ykC4WCngFcoVQYru5isOOupvxSu_ZqIc" + "slot_start": 1731471600000, + "slot_end": 1731477000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1J21ogENKuo-BCOrzHLQIUHr3yr7F7Ki9YBkOmnf6sTU" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -153515,9 +153634,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -153527,6 +153643,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -154145,22 +154262,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -154204,6 +154305,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -154297,6 +154399,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -154315,6 +154418,21 @@ 0, 0, 0, + 2, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -154635,8 +154753,19 @@ 0, 0, 0, - 2, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, 2, 0, 0, @@ -154649,36 +154778,39 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "closing-ceremonies", - "sourceId": "RUZK3B", - "title": "Closing Ceremonies", - "description": "The closing ceremonies will feature a discussion round with members of 0xPARC, The Long Now Foundation, and the Ethereum Foundation, followed by exclusive content, closing remarks, and a performance to conclude the event.", - "track": "", + "id": "clookup-composite-function-based-lookup-argument", + "sourceId": "TJ9TMF", + "title": "Clookup - Composite Function based Lookup Argument", + "description": "Presenting Clookup, a novel lookup protocol that enhances efficiency in verifiable computations. By using a composite function approach and multivariate polynomials within the sumcheck protocol, Clookup achieves optimal time complexity \\(O(m(m+n))\\) when processing \\(2^m\\) witness elements against a \\(2^n\\) table. This method eliminates the need to compute coefficient forms of composite functions.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Lookup", + "Arguments" + ], + "tags": [ + "Cryptography", + "ZKP" + ], "language": "en", "speakers": [ - "skylar-weaver", - "aya-miyaguchi", - "justin-glibert", - "gubsheep", - "nicholas-paul" + "wanseob-lim" ], "eventId": "devcon-7", - "slot_start": 1731661200000, - "slot_end": 1731668400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1zk6NkmsduzkZUpci9G4Ulqy-v_Ab9pktxWiTS7fPEh4" + "slot_start": 1731659400000, + "slot_end": 1731660600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1N-AwhGffiR0ykC4WCngFcoVQYru5isOOupvxSu_ZqIc" }, "vector": [ 0, @@ -154691,14 +154823,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -154866,10 +154997,6 @@ 0, 0, 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -155438,6 +155565,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -155496,6 +155627,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -155982,11 +156115,11 @@ 0, 0, 0, - 2, 0, 0, 2, 0, + 2, 0, 0, 0, @@ -156003,12 +156136,12 @@ }, { "session": { - "id": "cls-eth-escape-speed-hacking-challenge", - "sourceId": "RSYU7K", - "title": "[CLS] ETH Escape - Speed Hacking Challenge", - "description": "​Prize Pool: $50,000\r\n\r\n​A High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t", - "track": "Entertainment", - "type": "Mixed Formats", + "id": "closing-ceremonies", + "sourceId": "RUZK3B", + "title": "Closing Ceremonies", + "description": "The closing ceremonies will feature a discussion round with members of 0xPARC, The Long Now Foundation, and the Ethereum Foundation, followed by exclusive content, closing remarks, and a performance to conclude the event.", + "track": "", + "type": "Talk", "expertise": "", "audience": "Engineering", "featured": false, @@ -156016,12 +156149,18 @@ "keywords": [], "tags": [], "language": "en", - "speakers": [], + "speakers": [ + "skylar-weaver", + "aya-miyaguchi", + "justin-glibert", + "gubsheep", + "nicholas-paul" + ], "eventId": "devcon-7", - "slot_start": 1731551400000, - "slot_end": 1731573000000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0" + "slot_start": 1731661200000, + "slot_end": 1731668400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1zk6NkmsduzkZUpci9G4Ulqy-v_Ab9pktxWiTS7fPEh4" }, "vector": [ 0, @@ -156033,11 +156172,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -156045,6 +156179,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -156212,6 +156347,11 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -157346,31 +157486,25 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-block-construction", - "sourceId": "3AWFTE", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Block construction", - "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum’s roadmap. Join us here to discuss the “infinite endgame” for block construction. We'll cover PBS, MEV, role of validators vs. builders, centralization risks, and more!\r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", - "track": "[CLS] Infinite Endgames by Ethereum Magicians", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Community", + "id": "cls-eth-escape-speed-hacking-challenge", + "sourceId": "RSYU7K", + "title": "[CLS] ETH Escape - Speed Hacking Challenge", + "description": "​Prize Pool: $50,000\r\n\r\n​A High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "Blobs", - "MEV", - "PBS" - ], + "tags": [], "language": "en", - "speakers": [ - "alex-stokes" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731655800000, + "slot_start": 1731551400000, + "slot_end": 1731573000000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yeTJ8P67T5QYFuo5u1uIU8PtyMBoM_1mpCtwWM27BQc" + "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0" }, "vector": [ 0, @@ -157382,6 +157516,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -157390,7 +157525,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -157562,7 +157696,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -158113,7 +158246,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -158150,7 +158282,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -158175,7 +158306,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -158673,13 +158803,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 2, @@ -158690,39 +158820,41 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ethconomics", - "sourceId": "UFX3NX", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethconomics", - "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum's roadmap. Join us here to discuss the \"infinite endgame\" for Ethereum's economic model. We'll cover the role of Ether in the network's security, issuance proposals, out-of-protocol economic influences, and more! \r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", + "id": "cls-ethereum-magicians-infinite-endgames-block-construction", + "sourceId": "3AWFTE", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Block construction", + "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum’s roadmap. Join us here to discuss the “infinite endgame” for block construction. We'll cover PBS, MEV, role of validators vs. builders, centralization risks, and more!\r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", - "featured": true, + "expertise": "Intermediate", + "audience": "Community", + "featured": false, "doNotRecord": false, - "keywords": [ - "Ethconomics", - "Issuance" - ], + "keywords": [], "tags": [ - "Economics", + "Blobs", "MEV", - "Staking" + "PBS" ], "language": "en", "speakers": [ - "tim-beiko" + "alex-stokes" ], "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731661200000, + "slot_start": 1731650400000, + "slot_end": 1731655800000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yfoTOM-8vuH0ZUXAvbG6H3K4-yhQUtdboeWI5L5uJ7M" + "resources_presentation": "https://docs.google.com/presentation/d/1yeTJ8P67T5QYFuo5u1uIU8PtyMBoM_1mpCtwWM27BQc" }, "vector": [ 0, @@ -158914,7 +159046,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -159465,9 +159596,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -159498,13 +159629,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -159529,6 +159660,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -159592,7 +159724,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -160029,7 +160160,6 @@ 0, 2, 0, - 2, 0, 0, 0, @@ -160037,6 +160167,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -160047,31 +160180,34 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ethereum-execution", - "sourceId": "S8NCDC", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethereum Execution", - "description": "A fishbowl-style discussion with core Ethereum contributors and community to publicly discuss the \"endgame\" of execution on Ethereum. We will discuss what the evolution of Ethereum’s execution layer will look like, L1 vs. L2, settlement vs. execution, enshrined rollups, consensus changes vs. client performance improvements, etc.", + "id": "cls-ethereum-magicians-infinite-endgames-ethconomics", + "sourceId": "UFX3NX", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethconomics", + "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum's roadmap. Join us here to discuss the \"infinite endgame\" for Ethereum's economic model. We'll cover the role of Ether in the network's security, issuance proposals, out-of-protocol economic influences, and more! \r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Expert", - "audience": "Research", - "featured": false, + "expertise": "Beginner", + "audience": "Engineering", + "featured": true, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Ethconomics", + "Issuance" + ], "tags": [ - "Core Protocol", - "In-protocol Account Abstraction", - "Rollups" + "Economics", + "MEV", + "Staking" ], "language": "en", "speakers": [ - "lightclient" + "tim-beiko" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731650400000, + "slot_start": 1731655800000, + "slot_end": 1731661200000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Ovum9wCpn-eOO_GaydQ7myGTVXFB4g6lDX0Btv4ApMI" + "resources_presentation": "https://docs.google.com/presentation/d/1yfoTOM-8vuH0ZUXAvbG6H3K4-yhQUtdboeWI5L5uJ7M" }, "vector": [ 0, @@ -160242,7 +160378,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -160265,6 +160400,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -160814,6 +160951,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -160831,7 +160969,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -160847,6 +160984,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -160854,7 +160992,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -160941,6 +161078,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -161031,15 +161176,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -161391,38 +161527,37 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ux", - "sourceId": "QRG8QW", - "title": "[CLS] Ethereum Magicians Infinite Endgames: UX", - "description": "UX has been at the forefront of Ethereum recently, as standards for Account and Chain Abstraction have been gaining significant traction in the space.\r\n\r\nJoin us (literally! This panel will be “fishbowl style”) as we discuss the challenges that we will need to figure out first, such as cross-L2 key management, asset handling and transactions; avoiding fragmentation (liquidity, network, users); coordinating standards across L2s and wallets; and more", + "id": "cls-ethereum-magicians-infinite-endgames-ethereum-execution", + "sourceId": "S8NCDC", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethereum Execution", + "description": "A fishbowl-style discussion with core Ethereum contributors and community to publicly discuss the \"endgame\" of execution on Ethereum. We will discuss what the evolution of Ethereum’s execution layer will look like, L1 vs. L2, settlement vs. execution, enshrined rollups, consensus changes vs. client performance improvements, etc.", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Intermediate", - "audience": "Product", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "ERC-4337" - ], + "keywords": [], "tags": [ - "Account Abstraction", - "Cross-L2", - "UI/UX" + "Core Protocol", + "In-protocol Account Abstraction", + "Rollups" ], "language": "en", "speakers": [ - "tom-teman" + "lightclient" ], "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731645000000, + "slot_start": 1731645000000, + "slot_end": 1731650400000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1O8Er1O0dSSedqAxQY9z1pjTRU-Hr46AyiOlBS6Dnvq0" + "resources_presentation": "https://docs.google.com/presentation/d/1Ovum9wCpn-eOO_GaydQ7myGTVXFB4g6lDX0Btv4ApMI" }, "vector": [ 0, @@ -161593,6 +161728,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -161616,7 +161752,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -162183,6 +162318,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162205,6 +162341,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162214,7 +162351,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162222,7 +162358,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162363,7 +162498,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162386,6 +162520,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162725,15 +162860,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -162747,28 +162883,33 @@ }, { "session": { - "id": "cls-formal-verification-hangout", - "sourceId": "ZTHE3N", - "title": "[CLS] Formal Verification Hangout", - "description": "A low key, informal, self-organized event hosted within the Devcon venue* to explore interesting topics in Formal Verification.\r\n\r\nThe event will be casual, with minimal talks/programming, and geared towards facilitating discussions and allowing researchers to connect with others in the field.\r\n\r\n​Agenda\r\n\r\n​2:00 - 2:15 – Welcome\r\n2:15 - 3:30 – Fishbowl Panel\r\n3:30 - 4:00 – Break\r\n4:00 - 5:00 – Lightning Talks**\r\n5:00 - 6:00 – Discussion Groups\r\n6:00 onwards – Informal Discussions", - "track": "[CLS] Formal Verification Hangout, FV Team", - "type": "Mixed Formats", + "id": "cls-ethereum-magicians-infinite-endgames-ux", + "sourceId": "QRG8QW", + "title": "[CLS] Ethereum Magicians Infinite Endgames: UX", + "description": "UX has been at the forefront of Ethereum recently, as standards for Account and Chain Abstraction have been gaining significant traction in the space.\r\n\r\nJoin us (literally! This panel will be “fishbowl style”) as we discuss the challenges that we will need to figure out first, such as cross-L2 key management, asset handling and transactions; avoiding fragmentation (liquidity, network, users); coordinating standards across L2s and wallets; and more", + "track": "[CLS] Infinite Endgames by Ethereum Magicians", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "ERC-4337" + ], "tags": [ - "Formal", - "Verification" + "Account Abstraction", + "Cross-L2", + "UI/UX" ], "language": "en", - "speakers": [], + "speakers": [ + "tom-teman" + ], "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731409200000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1KG701RsIoq1QyT_uxs6WdIDJVZLJz0WL2Zcdl1b-gzg" + "slot_start": 1731639600000, + "slot_end": 1731645000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1O8Er1O0dSSedqAxQY9z1pjTRU-Hr46AyiOlBS6Dnvq0" }, "vector": [ 0, @@ -162788,7 +162929,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -162963,6 +163103,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -163561,6 +163702,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -163568,6 +163710,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -163710,6 +163853,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -163729,8 +163873,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -164075,11 +164217,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -164093,31 +164235,28 @@ }, { "session": { - "id": "cls-programmable-cryptography", - "sourceId": "UTCRP8", - "title": "[CLS] Programmable Cryptography", - "description": "The Programmable Cryptography CLS hosts a series of talks exploring how advanced cryptography can reshape digital infrastructure beyond blockchain and trust infrastructure.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "id": "cls-formal-verification-hangout", + "sourceId": "ZTHE3N", + "title": "[CLS] Formal Verification Hangout", + "description": "A low key, informal, self-organized event hosted within the Devcon venue* to explore interesting topics in Formal Verification.\r\n\r\nThe event will be casual, with minimal talks/programming, and geared towards facilitating discussions and allowing researchers to connect with others in the field.\r\n\r\n​Agenda\r\n\r\n​2:00 - 2:15 – Welcome\r\n2:15 - 3:30 – Fishbowl Panel\r\n3:30 - 4:00 – Break\r\n4:00 - 5:00 – Lightning Talks**\r\n5:00 - 6:00 – Discussion Groups\r\n6:00 onwards – Informal Discussions", + "track": "[CLS] Formal Verification Hangout, FV Team", "type": "Mixed Formats", - "expertise": "", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "justin-glibert", - "gubsheep", - "barry", - "albert-ni", - "vitalik-buterin" + "tags": [ + "Formal", + "Verification" ], + "language": "en", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731646800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1KpnGjqycfpLNFKUjuTryELdVgZfiVhV0qOcH-f6orS0" + "slot_start": 1731394800000, + "slot_end": 1731409200000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1KG701RsIoq1QyT_uxs6WdIDJVZLJz0WL2Zcdl1b-gzg" }, "vector": [ 0, @@ -164134,11 +164273,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -164306,15 +164445,10 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -165086,6 +165220,11 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -165424,6 +165563,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -165442,45 +165582,31 @@ }, { "session": { - "id": "common-knowledge-machines", - "sourceId": "XJPE8K", - "title": "Common Knowledge Machines", - "description": "Common knowledge is a precondition for collective action. Yet, increasing polarization in information ecosystems risks undermining common knowledge formation. This talk introduces Community Posts, a mechanism that leverages diversification and zero-knowledge proofs to help people identify divides, bridge them and find common ground, fostering greater common knowledge in social networks.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": true, + "id": "cls-programmable-cryptography", + "sourceId": "UTCRP8", + "title": "[CLS] Programmable Cryptography", + "description": "The Programmable Cryptography CLS hosts a series of talks exploring how advanced cryptography can reshape digital infrastructure beyond blockchain and trust infrastructure.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", + "featured": false, "doNotRecord": false, - "tags": [ - "Censorship Resistance", - "Collective Intelligence", - "Consensus Mechanisms", - "Coordination", - "Identity" - ], - "keywords": [ - "Stellar", - "Punk" - ], - "duration": 1057, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "6VJYBNZioHg", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673356d73a168eb5357cf419.vtt", - "transcript_text": " All right, so let me get this on the right slide here. Common knowledge. So what is common knowledge? Why does it matter? So common knowledge is not just that you know I'm standing here, it's that you know that I know that you know ad infinitum. It's a very different thing than just knowing that I'm here. And a classic example of this is the Romanian Revolution in 1989. For years, everyone knew that this dictator, Chia Ceausescu, was a tyrant, but nothing ever happened. And it wasn't until actually a simple act during one of his public speeches, a live broadcast whistle that cascaded into many whistles, that a revolution began. And the key wasn't just that everybody saw, the key was not just that everybody was unhappy, but they saw that everybody else was unhappy. So we've had similar moments in American history. I'm American, so that's my history. But my contention is actually common knowledge is getting harder to get off the ground. And that's because of increasing political polarization. And while political polarization predates the internet, it certainly has been accelerated in the digital age. And why is it so bad? Well, if we can't find common ground, if we can't have shared beliefs, then collective action becomes really hard, and collective action is the stuff for political movements and also for government and legitimate governance. And so on the international stage this is really important important so unions stay unified and can differentiate their allies from their adversaries and marshal support and not collapse into the chaos of competing narratives which we seem to be trending towards. And also common knowledge lets us solve higher forms of cooperation problem, for example, like climate change that requires consensus and agreement about the facts. So since this is DevCon and an Ethereum conference, it's worth acknowledging actually that Ethereum itself is an example of a common knowledge machine. It produces or it seeks to actually produce an immutable ledger about shared global state. Another obvious example of common knowledge machines are things like blue sky, forecaster, lens, or X. These are the functional equivalent of public squares, but actually online. But of course here, common knowledge rarely ever gets off the ground, and instead we just have divisions and competing narratives about reality and which one is true. So today I want to introduce a quick mechanism and outline on the principles to sort of nudge your thoughts, and you can read more if you want in my writings. So the idea is called community posts, and everybody here who participates in some social media platform has some set of followers. And the idea is instead of blasting a post to all of your followers, you first stress test a post across different groups of followers who don't necessarily talk, listen, or agree with one another to gauge what resonates before it's widely shared. And so here's how it works. If you look at your followers, your set of followers, they actually all have differences in behavior measured by their likes, their reposts, who follows them, and who they follow, their connections. And you can aggregate this information about observed behavior using things like ZK-SNARKs and put people in clusters as represented by circles here. And the idea is that you pick a subset of uncorrelated followers on your social graph, people who behave differently on the platform, balance for reach with a minimum diversification threshold. Now, these polarity subsets aren't an echo chamber. What they are is a sampling or a random sampling of some set of your followers balanced across different perspectives. And there'll be multiple subsets to choose from. For example, you can handpick key anchors or key thought leaders or experts and then diversify against them in different combinations to fill the remaining set. Now, once you pick your subset, you send that post to the subset with a zero-knowledge proof confirming that recipients follow you without revealing your identity. Now some might disagree with the post and send ZK feedback to you, but some might actually take it further and pass it on to subsets, polarity subsets of their followers. And these rounds repeat forming a tree of polarity subsets across the social graph, which essentially pushes your post across very diverse parts of the social graph, allowing you to gauge cross-tribal appeal at every step and every layer through repost rates and feedback. And of course, if people receive this, get a notification, ZK posted by the end people you follow, or end people you follow boosted this post, and so on. Now, the final step is the post goes public. Once it gains enough support across and reaches that diversification threshold, and it's passed its social stress test, then the post goes public, and you can merge into your open feed, and anyone who has reposted it can post it to all their followers, and so on. And then, you know, any remaining divides as represented by red here on these red parts of the social graph, you can use community notes, which we're all familiar with, to bridge and add context. And this is really low-hanging fruit divides. So anyways, this is the summary of the mechanism. I think it works because essentially what you're doing is you're reversing the cycle that happens on social media of context collapse, controversy, cancellation, and capture. And these are things where social media leverages divisions to create more divisions. And you reverse that cycle with diversification, discounts, and bridging to restore common ground. Okay. I think that's it for five minutes. I can take any of your questions. Thank you, Chris. I think that's it for five minutes. I can take any of your questions. . That was kind of a complex mechanism for five minutes. Who wants to ask a question? Who wants to ask a question? Here, please. This is amazing. What do we do next? What's like a next step here? Yeah, so there are a lot of experiments with social graphs right now in Web3. FarCaster and Lens are an example. And so you can leverage like ZK-SNARKs, zero knowledge proofs to actually calculate this information without revealing the identities and participants in a social graph and start leverage like ZKStarks, Zero Knowledge Proofs, to actually calculate this information without revealing the identities and participants in a social graph and start to create a more meaningful parallel attention feed to show, OK, what are posts where there's wide agreement on? And instead of focusing on the attention and the rage bait that comes from a global attention auction, you can focus your attention on, OK, well, what are the things where there's agreement and then build on that agreement? Yeah? We can have one more question. Do you envision this being applicable to, like, more popular social media, like maybe a plug-in for Twitter or whatever? Yeah, it could apply to any social media. It could apply, it's a roadmap for making X a common knowledge machine. I think that actually was always the aspiration around a public square and the Ceausescu example. It's also applicable to TikTok. It's applicable to really any social network. And it's just a more intelligent attention mechanism, right, that gets us, that sort of reverses the cycle of let me, you know, hit my dopamine receptors with division towards, let me see what I can find common ground with and build on that. Okay. Thank you, everybody. Thank you. Thank you. I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool I'm a fool So for this Wasim, he will not He don't want to use the modern leader Yes And you just growing up and then you're all, you know, like, in the state, and then you're going down, and after that, you just wait until it wasn't finished over. You know, just like that. Okay. Okay. Okay. Are you ready? Oh, yes, I am. Okay, everyone. Next, we have The Shane Male Gaze by Wazim Z. Alcindi. Please, give him a warm welcome. Hello, everybody. It's slightly out of place to have such cheerful music introducing this talk perhaps so the title of it is called The Chainmail Gaze and hopefully the reasons for that will become apparent as we go on but I'm sure you've all heard of the mail gaze and the kind of externalities and you know unfavorable things that come with that but what about the chain male gaze well hopefully we'll find out not got very long so i'll try to you know give you a survey of what's actually quite extensive anthropological and philosophical research project okay some pictures of big strong men and their swords looking into the distance, perhaps thinking about lands to conquer. Short poetic refrain, the church and the network, zeal and time, death and money, all sides of the same coin. a phwysig, pob rhan o'r un coin. Rwy'n hoff i siarad â chi am brosiect cymhwysol sy'n arwain at y lle rydyn ni'n mynd i, a'i enw'n enw'n ymwneud â'r ddyfyniadau ar gyfer cyfrif, yn edrych ar y in the technology space that might not be immediately apparent. For as long as there's been financial capital, risk and speculation have orbited, manipulated and harnessed it. As narrative feedback machines, simultaneously reading and rewriting realities, markets exist as a distributed conversation among speculators driven by profit motives and appetite for divination and prophecy. Today, new strains of techno-colonialism are emerging, which are the latest of a series of echoes throughout Western history. An ascendant cabal of technology elites are attempting to reshape the world in their favor whilst hiding in plain sight behind the technologies that have enriched them. Theirs is a Promethean zealotry without faith, affecting an aura of divine sanction for the purposes of elevating the ego, enriching the chosen ones, and creating empires of various stripes. But was it not? Always so. I want to read you a short story, fictional speculation, about where we might be going in the future. It's called Seething Like a State. Decentralization has a cost, the price of anarchy. The price is always due, but the rewards weren't cheap to reap. So solid, CCRU. What most did not expect was that payment would become due at the grandest scales of governance. The West failure state, forged under the fire of peer pressure, was ambushed by upstart modes of power, opening new vistas of communication, commodification and communion. The orientations that nation states had used to enshrine their power only made it easier to undermine them. The bigger they were, the harder they fell. Brextopia, the European Union, NATO's cave, the United State machine, all returned to dust. The decline of the nation state in the roaring 20s became a canon of canonicity for an entire generation of sole traders. It wasn't even just the bit leavers. In those days, there were many networks, many messiahs, many ideologics, all with their own profit motives. So many of you have doubtless heard of this concept of the network state that has emerged in the last few years. Exit fantasies, arguably fueled by the failure or the shortcomings the shortfall of the full promise and the dream of web3 i'm going to read you a short section from belagi's universe self self-titled book from 2022 a network state is a social network with a moral innovation a sense of national consciousness a recognized recognized founder, a capacity for collective action, an in-person level of civility, an integrated cryptocurrency, a consensual government limited by a social smart contract, an archipelago of crowdfunded physical territories, a virtual capital, and an on-chain census that proves a large enough population, income, and real estate footprint to attain a measure of diplomatic recognition. The magic words in here are recognized founder and diplomatic recognition, and territory, I would say. So these projects carry echoes, in my mind at least, of some of the earliest expeditions set out from the West in search of new territories to conquer and subjugate. So many of you have doubtless heard of things like Liberland, Sealand, Seasteading Institutes. This is the Zahidi-designed Metaverse HQ of Liberland on screen here. There's been so many attempts to make like crypto islands, Bitcoin cruise ships, and they've all failed. It's quite interesting. But what seems to be different now is the level of capital on hand as a result of market success of these technologies to the people that want to reshape the map of the world in their own, you know, to their own preferences, into their own cause. We know that leaders of nation states, we even have leaders of nation states that are cheerleading some of these technologies. Nayib Keri, the authoritarian strongman in El Salvador, would like to build a Bitcoin city financed by volcano bonds in his country. He's not done it yet. But meanwhile, he's removed the judiciary, removed term limits, and instituted one-party rule. And most of the Bitcoins are cheering this on. So I ask myself, are we still in this for the freedom? And now, you know, made possible by Ethereum, DAOs, and all the rest of it, we have projects like Aleph, Urbit, and even Praxis. Praxis on the left and Prospera on the right. So these projects are trying to build physical cities, private territories, network states, or at least what may develop into the Bellagio concept of the nation state. And it's at this point I want to introduce the chainmail gaze. Today's tech overlords are the descendants of Europe's crusaders well-financed zealous fanatics wreaking destruction on the planetary other in the name of their greater good the Vatican sponsored waves of Levantine invasions that began in the late 11th century with a midwife of capitalism, colonialism, and technology as we know it today. With the network state organizational concept, a cadre of powerful ideologues blessed with tokenized wealth, a toying with the prospect of reshaping national frontiers, mirroring the desires of Frankish noblemen and their nightly orders in the Levant a thousand years ago. And that's all the time I have. Seven minutes for a thousand years of Western history. Thank you very much.", - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731409800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1a63MEhn5HWzDRARwTVIqwlXGcTuEurRAij2MM5-ACMI", - "resources_slides": null, "speakers": [ - "puja-ohlhaver" - ] + "justin-glibert", + "gubsheep", + "barry", + "albert-ni", + "vitalik-buterin" + ], + "eventId": "devcon-7", + "slot_start": 1731639600000, + "slot_end": 1731646800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1KpnGjqycfpLNFKUjuTryELdVgZfiVhV0qOcH-f6orS0" }, "vector": [ 0, @@ -165494,6 +165620,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -165666,6 +165795,58 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 6, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -165678,7 +165859,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -166255,7 +166435,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -166270,7 +166449,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -166369,56 +166547,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -166786,8 +166914,6 @@ 2, 0, 0, - 0, - 0, 2, 0, 0, @@ -166800,42 +166926,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "community-notes", - "sourceId": "8F3HQM", - "title": "Community Notes", - "description": "Community Notes allows regular X users to collaboratively add context to potentially misleading posts. It uses a transparent and verifiable mechanism that aims to be credibly neutral by only showing posts liked by users who typically disagree.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "common-knowledge-machines", + "sourceId": "XJPE8K", + "title": "Common Knowledge Machines", + "description": "Common knowledge is a precondition for collective action. Yet, increasing polarization in information ecosystems risks undermining common knowledge formation. This talk introduces Community Posts, a mechanism that leverages diversification and zero-knowledge proofs to help people identify divides, bridge them and find common ground, fostering greater common knowledge in social networks.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, + "audience": "Research", + "featured": true, "doNotRecord": false, - "keywords": [ - "d/acc" - ], "tags": [ "Censorship Resistance", "Collective Intelligence", - "Consensus Mechanisms" + "Consensus Mechanisms", + "Coordination", + "Identity" ], - "language": "en", - "speakers": [ - "jay-baxter" + "keywords": [ + "Stellar", + "Punk" ], + "duration": 468, + "language": "en", + "sources_swarmHash": "2fadd824928c32a979645300678ee71dea6d46f238ba5f1acf48e3791e8e8005", + "sources_youtubeId": "B1oh1WrU-7g", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731561600000, - "slot_end": 1731562200000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/10k5sMswiuZ6sjCWh6_3DzYLI8Ix836tP-o0-fhgeUCI" + "slot_start": 1731409200000, + "slot_end": 1731409800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1a63MEhn5HWzDRARwTVIqwlXGcTuEurRAij2MM5-ACMI", + "resources_slides": null, + "speakers": [ + "puja-ohlhaver" + ] }, "vector": [ - 0, - 6, 0, 0, 0, @@ -166847,6 +166984,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -167606,9 +167744,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -167622,6 +167761,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -167727,6 +167867,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -167766,9 +167907,8 @@ 0, 0, 0, - 2, - 0, 0, + 2, 0, 0, 0, @@ -168138,8 +168278,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -168156,40 +168296,35 @@ }, { "session": { - "id": "comparing-slashing-penalties-on-proof-of-stake-networks", - "sourceId": "YJZT3K", - "title": "Comparing Slashing Penalties on Proof-of-Stake Networks", - "description": "With the support of the Ethereum Foundation, we have performed an analysis of slashing penalties on the seventy largest proof-of-stake cryptocurrency networks. Using insights from institutional economics and game theory, we consider variance in slashing penalties in terms of the conditions that trigger slashing, the magnitude of penalties contemplated, and the limited cases where human judgment plays a role in determining such penalties.", - "track": "Cryptoeconomics", + "id": "community-notes", + "sourceId": "8F3HQM", + "title": "Community Notes", + "description": "Community Notes allows regular X users to collaboratively add context to potentially misleading posts. It uses a transparent and verifiable mechanism that aims to be credibly neutral by only showing posts liked by users who typically disagree.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Slashing" + "d/acc" ], "tags": [ - "Governance", - "Game Theory", - "Economics", - "slashing", - "Economics", - "Game Theory", - "Governance" + "Censorship Resistance", + "Collective Intelligence", + "Consensus Mechanisms" ], "language": "en", "speakers": [ - "eric-alston" + "jay-baxter" ], "eventId": "devcon-7", - "slot_start": 1731496800000, - "slot_end": 1731497400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1U1W0kONT5CqQY5olh7ieFlQWhiN9s7HXZjQqM1AuBzg" + "slot_start": 1731561600000, + "slot_end": 1731562200000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/10k5sMswiuZ6sjCWh6_3DzYLI8Ix836tP-o0-fhgeUCI" }, "vector": [ - 0, 0, 6, 0, @@ -168935,7 +169070,8 @@ 0, 0, 0, - 6, + 0, + 0, 0, 0, 0, @@ -169023,7 +169159,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169077,6 +169212,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -169123,6 +169260,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -169149,7 +169287,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169493,7 +169630,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -169506,44 +169642,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "conditional-recall", - "sourceId": "XTQUDR", - "title": "Conditional Recall", - "description": "In the neon-lit nights of 2025, Johnson & Johnson unveiled X. A pill, not larger than a snowflake, but it promised a tempest of change. This miraculous drug didn't just allow people to cherry-pick memories to erase from their minds, it also can credibly leave a reminder in people's minds that those memories has been vanished, forever.\r\nWe explore the game theoretic implications of a technology (such as TEEs) that allows players to commit to forget information and discuss several applications.", + "id": "comparing-slashing-penalties-on-proof-of-stake-networks", + "sourceId": "YJZT3K", + "title": "Comparing Slashing Penalties on Proof-of-Stake Networks", + "description": "With the support of the Ethereum Foundation, we have performed an analysis of slashing penalties on the seventy largest proof-of-stake cryptocurrency networks. Using insights from institutional economics and game theory, we consider variance in slashing penalties in terms of the conditions that trigger slashing, the magnitude of penalties contemplated, and the limited cases where human judgment plays a role in determining such penalties.", "track": "Cryptoeconomics", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "TEE", - "Commitment" + "Slashing" ], "tags": [ - "Mechanism design", + "Governance", "Game Theory", "Economics", - "commitment", + "slashing", "Economics", "Game Theory", - "Mechanism design" + "Governance" ], "language": "en", "speakers": [ - "sxysun", - "christoph-schlegel" + "eric-alston" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731650400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1jXv2kbSefJjmF8zhC0ibw1x1paaVWwuDjrd37N_Nzj8" + "slot_start": 1731496800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1U1W0kONT5CqQY5olh7ieFlQWhiN9s7HXZjQqM1AuBzg" }, "vector": [ 0, @@ -169743,8 +169878,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -170291,7 +170424,10 @@ 0, 0, 0, - 6, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -170380,6 +170516,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -170845,7 +170982,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -170868,46 +171004,44 @@ }, { "session": { - "id": "coordinating-intelligence-open-algorithm-development-for-science-ai-and-beyond", - "sourceId": "FZRMPJ", - "title": "Coordinating Intelligence : Open Algorithm Development for Science, AI, and Beyond", - "description": "The Innovation Game (TIG) is a market-based framework accelerating development of computational methods crucial to science, engineering, and AI. It creates a \"synthetic market\" where \"Innovators\" contribute methods and are rewarded based on adoption by \"Benchmarkers,\" who are rewarded for solving random instances of computational challenges. This enables price discovery for commercial and pre-commercial research, attracting private investment. TIG's hybrid licensing model ensures open collaborat", - "track": "Coordination", - "type": "Lightning Talk", + "id": "conditional-recall", + "sourceId": "XTQUDR", + "title": "Conditional Recall", + "description": "In the neon-lit nights of 2025, Johnson & Johnson unveiled X. A pill, not larger than a snowflake, but it promised a tempest of change. This miraculous drug didn't just allow people to cherry-pick memories to erase from their minds, it also can credibly leave a reminder in people's minds that those memories has been vanished, forever.\r\nWe explore the game theoretic implications of a technology (such as TEEs) that allows players to commit to forget information and discuss several applications.", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Innovation", - "Algorithms", - "Optimised Proof of Work" + "TEE", + "Commitment" ], "tags": [ - "Coordination", - "DeSci", + "Mechanism design", + "Game Theory", "Economics", - "proof", - "optimised", - "work", - "Coordination", - "DeSci", - "Economics" + "commitment", + "Economics", + "Game Theory", + "Mechanism design" ], "language": "en", "speakers": [ - "dr-john-fletcher-phd", - "kilian-hikaru-scheutwinkel" + "sxysun", + "christoph-schlegel" ], "eventId": "devcon-7", - "slot_start": 1731566400000, - "slot_end": 1731567000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1LhUMD8kPbukRuIeQXcyC9Nzn52Zdr6JH80byPktkErk" + "slot_start": 1731648600000, + "slot_end": 1731650400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1jXv2kbSefJjmF8zhC0ibw1x1paaVWwuDjrd37N_Nzj8" }, "vector": [ 0, 0, + 6, 0, 0, 0, @@ -170917,9 +171051,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -171654,6 +171785,9 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, @@ -171778,7 +171912,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -171799,15 +171932,17 @@ 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, @@ -171869,8 +172004,7 @@ 0, 0, 2, - 2, - 2, + 0, 0, 0, 0, @@ -172210,8 +172344,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -172228,34 +172362,42 @@ }, { "session": { - "id": "coordination-accelerationism-a-manifesto", - "sourceId": "NGXHAA", - "title": "Coordination Accelerationism: A Manifesto", - "description": "In this talk, we place crypto in the context of evolutionary timescale. We present an overview of the various types of coordination systems, their advantages and weaknesses. The most robust type of coordination mechanism is something we term as, self-enforcing coordination systems (SECS) - which do not require an authority, a committee or even a majority of entities to enforce the conditions of coordination. We also show how to build the most general form of SECS.", + "id": "coordinating-intelligence-open-algorithm-development-for-science-ai-and-beyond", + "sourceId": "FZRMPJ", + "title": "Coordinating Intelligence : Open Algorithm Development for Science, AI, and Beyond", + "description": "The Innovation Game (TIG) is a market-based framework accelerating development of computational methods crucial to science, engineering, and AI. It creates a \"synthetic market\" where \"Innovators\" contribute methods and are rewarded based on adoption by \"Benchmarkers,\" who are rewarded for solving random instances of computational challenges. This enables price discovery for commercial and pre-commercial research, attracting private investment. TIG's hybrid licensing model ensures open collaborat", "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Forking" + "Innovation", + "Algorithms", + "Optimised Proof of Work" ], "tags": [ - "fork", - "Collective Intelligence", - "Consensus", - "Coordination" + "Coordination", + "DeSci", + "Economics", + "proof", + "optimised", + "work", + "Coordination", + "DeSci", + "Economics" ], "language": "en", "speakers": [ - "sreeram-kannan" + "dr-john-fletcher-phd", + "kilian-hikaru-scheutwinkel" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A" + "slot_start": 1731566400000, + "slot_end": 1731567000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1LhUMD8kPbukRuIeQXcyC9Nzn52Zdr6JH80byPktkErk" }, "vector": [ 0, @@ -172458,9 +172600,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -173001,7 +173144,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -173030,9 +173172,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -173131,6 +173273,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -173222,7 +173365,8 @@ 0, 0, 0, - 0, + 2, + 2, 2, 0, 0, @@ -173557,13 +173701,12 @@ 0, 0, 0, + 2, 0, 0, 0, 2, 0, - 2, - 0, 0, 0, 0, @@ -173580,47 +173723,40 @@ }, { "session": { - "id": "copying-memory-in-evm-how-hard-can-that-be", - "sourceId": "JKFBN3", - "title": "Copying Memory in EVM, how hard can that be?", - "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "", + "id": "coordination-accelerationism-a-manifesto", + "sourceId": "NGXHAA", + "title": "Coordination Accelerationism: A Manifesto", + "description": "In this talk, we place crypto in the context of evolutionary timescale. We present an overview of the various types of coordination systems, their advantages and weaknesses. The most robust type of coordination mechanism is something we term as, self-enforcing coordination systems (SECS) - which do not require an authority, a committee or even a majority of entities to enforce the conditions of coordination. We also show how to build the most general form of SECS.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Optimisations", - "Compilers" + "Forking" ], "tags": [ - "Core Protocol", - "Gas", - "Developer Infrastructure", - "compilers", - "optimised", - "Core Protocol", - "Developer Infrastructure", - "Gas" + "fork", + "Collective Intelligence", + "Consensus", + "Coordination" ], "language": "en", "speakers": [ - "elia-anzuoni" + "sreeram-kannan" ], "eventId": "devcon-7", - "slot_start": 1731471600000, - "slot_end": 1731472200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA" + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -173628,6 +173764,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -174360,6 +174497,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -174372,7 +174510,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -174389,6 +174526,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -174407,7 +174545,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -174510,6 +174647,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -174578,10 +174719,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 2, 0, 0, @@ -174915,10 +175054,11 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -174929,7 +175069,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -174937,42 +175076,45 @@ }, { "session": { - "id": "corruption-kyc-and-the-cost-of-compliance", - "sourceId": "8FQ3HT", - "title": "Corruption, KYC and the Cost of Compliance", - "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "id": "copying-memory-in-evm-how-hard-can-that-be", + "sourceId": "JKFBN3", + "title": "Copying Memory in EVM, how hard can that be?", + "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "Compliance", - "Illicit Financial Flows", - "KYC/AML" + "Optimisations", + "Compilers" ], "tags": [ - "Anonymity", - "Censorship Resistance", - "Civil Resistance" + "Core Protocol", + "Gas", + "Developer Infrastructure", + "compilers", + "optimised", + "Core Protocol", + "Developer Infrastructure", + "Gas" ], "language": "en", "speakers": [ - "jarrad-hope" + "elia-anzuoni" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU" + "slot_start": 1731471600000, + "slot_end": 1731472200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -175727,13 +175869,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -175763,6 +175904,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -175854,7 +175996,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -175939,7 +176080,8 @@ 2, 0, 0, - 0, + 2, + 2, 0, 0, 0, @@ -176272,7 +176414,6 @@ 0, 2, 0, - 2, 0, 0, 0, @@ -176285,46 +176426,43 @@ 0, 0, 0, + 2, + 0, + 0, 0 ] }, { "session": { - "id": "cross-l2-with-intent-addresses", - "sourceId": "BEWE3Q", - "title": "Cross L2 with Intent Addresses", - "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.", - "track": "Usability", + "id": "corruption-kyc-and-the-cost-of-compliance", + "sourceId": "8FQ3HT", + "title": "Corruption, KYC and the Cost of Compliance", + "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the", + "track": "Cypherpunk & Privacy", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "CCTP", - "bridging", - "chain-abstraction" + "Compliance", + "Illicit Financial Flows", + "KYC/AML" ], "tags": [ - "Architecture", - "Cross-L2", - "Account Abstraction", - "chain", - "abstraction", - "Account Abstraction", - "Architecture", - "Cross-L2" + "Anonymity", + "Censorship Resistance", + "Civil Resistance" ], "language": "en", "speakers": [ - "nalin-b", - "dc-posch" + "jarrad-hope" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU" }, "vector": [ 0, @@ -176332,9 +176470,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -176472,24 +176607,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -176532,10 +176649,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -176556,6 +176669,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -177127,13 +177241,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -177245,6 +177352,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -177265,9 +177373,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -177331,6 +177436,38 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -177627,10 +177764,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 2, + 0, 2, 0, 0, @@ -177649,40 +177788,43 @@ }, { "session": { - "id": "crypto-in-action-powering-ukraines-resilience", - "sourceId": "7JZGQJ", - "title": "Crypto in Action: Powering Ukraine's Resilience", - "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "cross-l2-with-intent-addresses", + "sourceId": "BEWE3Q", + "title": "Cross L2 with Intent Addresses", + "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Resilient infrastructure", - "Ukraine", - "crypto donations" + "CCTP", + "bridging", + "chain-abstraction" ], "tags": [ - "Civil Resistance", - "Coordination", - "Public good" + "Architecture", + "Cross-L2", + "Account Abstraction", + "chain", + "abstraction", + "Account Abstraction", + "Architecture", + "Cross-L2" ], "language": "en", "speakers": [ - "rev-miller" + "nalin-b", + "dc-posch" ], "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU" }, "vector": [ - 0, - 6, - 0, 0, 0, 0, @@ -177691,6 +177833,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -177827,6 +177970,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -178471,6 +178615,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -178481,6 +178626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -178527,7 +178673,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -178573,7 +178718,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -178622,6 +178766,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -178648,7 +178795,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -178980,16 +179126,16 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -179002,58 +179148,44 @@ }, { "session": { - "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy", - "sourceId": "UCZ83J", - "title": "Crypto is the Real World: Understanding the Cryptonative Economy", - "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", + "id": "crypto-in-action-powering-ukraines-resilience", + "sourceId": "7JZGQJ", + "title": "Crypto in Action: Powering Ukraine's Resilience", + "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Digital Sovereignty", - "Use Cases", - "Economics", - "cryptonative", - "Digital Sovereignty", - "Economics", - "Use Cases" - ], "keywords": [ - "Real world", - "Ecosystem", - "Cryptonativism" + "Resilient infrastructure", + "Ukraine", + "crypto donations" + ], + "tags": [ + "Civil Resistance", + "Coordination", + "Public good" ], - "duration": 991, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "Y0u6J1OmPXc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt", - "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731390600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s", - "resources_slides": null, "speakers": [ - "josef-je" - ] + "rev-miller" + ], + "eventId": "devcon-7", + "slot_start": 1731581400000, + "slot_end": 1731582000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -179819,7 +179951,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -179834,7 +179965,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -179863,7 +179993,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -179898,6 +180027,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -179939,6 +180073,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -180346,8 +180481,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -180362,51 +180497,52 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work", - "sourceId": "YNBTQR", - "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work", - "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.", - "track": "Layer 2", + "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy", + "sourceId": "UCZ83J", + "title": "Crypto is the Real World: Understanding the Cryptonative Economy", + "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.", + "track": "Real World Ethereum", "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, "tags": [ - "Protocol Design", - "Layer 2s", - "Rollups", - "explainer", - "Layer 2s", - "Protocol Design", - "Rollups" + "Digital Sovereignty", + "Use Cases", + "Economics", + "cryptonative", + "Digital Sovereignty", + "Economics", + "Use Cases" ], "keywords": [ - "Explainer" + "Real world", + "Ecosystem", + "Cryptonativism" ], - "duration": 1311, + "duration": 991, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "c1IbglrscSU", + "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c", + "sources_youtubeId": "Y0u6J1OmPXc", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt", - "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.", + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt", + "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.", "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731400200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg", + "slot_start": 1731389400000, + "slot_end": 1731390600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s", "resources_slides": null, "speakers": [ - "kelvin-fichter" + "josef-je" ] }, "vector": [ @@ -180416,7 +180552,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -181185,15 +181320,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, 2, 0, 0, @@ -181209,11 +181335,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -181243,6 +181364,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -181380,25 +181502,37 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -181712,7 +181846,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -181722,6 +181855,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -181732,43 +181869,48 @@ }, { "session": { - "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond", - "sourceId": "PQBKHF", - "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond", - "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.", - "track": "Security", + "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work", + "sourceId": "YNBTQR", + "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work", + "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.", + "track": "Layer 2", "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Parallel", - "EVM" - ], "tags": [ - "Scalability", - "Security", - "Fuzzing", - "EVM", - "parallel", - "Fuzzing", - "Scalability", - "Security" + "Protocol Design", + "Layer 2s", + "Rollups", + "explainer", + "Layer 2s", + "Protocol Design", + "Rollups" ], - "language": "en", - "speakers": [ - "minh-ho" + "keywords": [ + "Explainer" ], + "duration": 1311, + "language": "en", + "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d", + "sources_youtubeId": "c1IbglrscSU", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt", + "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.", "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE" + "slot_start": 1731398400000, + "slot_end": 1731400200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg", + "resources_slides": null, + "speakers": [ + "kelvin-fichter" + ] }, "vector": [ - 6, - 0, 0, 0, 0, @@ -181776,6 +181918,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -182505,8 +182648,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -182551,9 +182692,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -182573,6 +182716,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -182645,7 +182789,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -182712,7 +182855,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -182738,11 +182880,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -183067,10 +183211,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 2, 0, @@ -183084,43 +183228,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve", - "sourceId": "MZMQXY", - "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve", - "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya", - "track": "Cypherpunk & Privacy", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond", + "sourceId": "PQBKHF", + "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond", + "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "culture" + "Parallel", + "EVM" + ], + "tags": [ + "Scalability", + "Security", + "Fuzzing", + "EVM", + "parallel", + "Fuzzing", + "Scalability", + "Security" ], - "tags": [], "language": "en", "speakers": [ - "simona-pop", - "aya-miyaguchi" + "minh-ho" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731562200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8" + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE" }, "vector": [ + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -183300,7 +183454,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -183855,6 +184008,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -183993,6 +184148,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -184061,6 +184217,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -184086,6 +184243,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -184412,7 +184570,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -184424,9 +184582,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -184437,47 +184592,30 @@ }, { "session": { - "id": "cultivating-the-understory-building-resilient-daos", - "sourceId": "NRHH9B", - "title": "Cultivating the Understory : Building Resilient DAOs", - "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance", - "track": "Coordination", - "type": "Talk", + "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve", + "sourceId": "MZMQXY", + "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve", + "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya", + "track": "Cypherpunk & Privacy", + "type": "Panel", "expertise": "Beginner", "audience": "Community", - "featured": true, + "featured": false, "doNotRecord": false, - "tags": [ - "Coordination", - "DAO", - "Vision", - "resiliency", - "Coordination", - "DAO", - "Vision" - ], "keywords": [ - "Culture", - "Resilience" + "culture" ], - "duration": 1569, + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "274Uyrxv6uI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c", - "resources_slides": null, "speakers": [ - "songyi-lee" - ] + "simona-pop", + "aya-miyaguchi" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731562200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8" }, "vector": [ 0, @@ -184485,13 +184623,14 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -184664,6 +184803,40 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -184691,7 +184864,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -185319,7 +185491,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -185373,13 +185544,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -185452,36 +185621,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, @@ -185802,38 +185941,47 @@ }, { "session": { - "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages", - "sourceId": "NMKQYY", - "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages", - "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", + "id": "cultivating-the-understory-building-resilient-daos", + "sourceId": "NRHH9B", + "title": "Cultivating the Understory : Building Resilient DAOs", + "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", - "audience": "Product", - "featured": false, + "audience": "Community", + "featured": true, "doNotRecord": false, - "keywords": [ - "History", - "Culture" - ], "tags": [ - "Governance", - "Network State", - "Security", - "culture", - "Governance", - "Network State", - "Security" + "Coordination", + "DAO", + "Vision", + "resiliency", + "Coordination", + "DAO", + "Vision" ], - "language": "en", - "speakers": [ - "evin-mcmullen" + "keywords": [ + "Culture", + "Resilience" ], + "duration": 1569, + "language": "en", + "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d", + "sources_youtubeId": "274Uyrxv6uI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731494400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c", + "resources_slides": null, + "speakers": [ + "songyi-lee" + ] }, "vector": [ 0, @@ -185841,13 +185989,13 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -185983,7 +186131,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -186048,6 +186195,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -186574,7 +186722,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -186621,7 +186768,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -186670,7 +186816,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -186679,6 +186824,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -186732,11 +186878,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -186809,9 +186957,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -187144,8 +187293,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -187158,34 +187307,38 @@ }, { "session": { - "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter", - "sourceId": "QPQZJR", - "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter", - "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?", + "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages", + "sourceId": "NMKQYY", + "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages", + "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.", "track": "Cypherpunk & Privacy", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Latency" + "History", + "Culture" ], "tags": [ - "latency", - "Censorship Resistance", - "Ethereum Roadmap", - "Not financial" + "Governance", + "Network State", + "Security", + "culture", + "Governance", + "Network State", + "Security" ], "language": "en", "speakers": [ - "sebastian-buergel" + "evin-mcmullen" ], "eventId": "devcon-7", - "slot_start": 1731493200000, - "slot_end": 1731493800000, + "slot_start": 1731493800000, + "slot_end": 1731494400000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE" + "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c" }, "vector": [ 0, @@ -187335,6 +187488,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -187400,7 +187554,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -187927,6 +188080,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -187973,6 +188127,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188021,6 +188176,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188074,7 +188230,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -188163,8 +188318,6 @@ 0, 0, 2, - 2, - 2, 0, 0, 0, @@ -188488,10 +188641,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -188505,41 +188658,48 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "dacc-closing-panel", - "sourceId": "HTKUVS", - "title": "d/acc closing panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter", + "sourceId": "QPQZJR", + "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter", + "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?", + "track": "Cypherpunk & Privacy", "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Latency" + ], + "tags": [ + "latency", + "Censorship Resistance", + "Ethereum Roadmap", + "Not financial" + ], "language": "en", "speakers": [ - "vitalik-buterin", - "eli-dourado" + "sebastian-buergel" ], "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731584400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s" + "slot_start": 1731493200000, + "slot_end": 1731493800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE" }, "vector": [ 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -188728,7 +188888,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -189422,6 +189581,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -189467,6 +189627,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -189510,9 +189671,8 @@ 0, 0, 0, - 0, - 0, - 0, + 2, + 2, 0, 0, 0, @@ -189838,13 +189998,14 @@ 2, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -189856,50 +190017,32 @@ }, { "session": { - "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds", - "sourceId": "3E7R7G", - "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds", - "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "dacc-closing-panel", + "sourceId": "HTKUVS", + "title": "d/acc closing panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "DAO", - "Governance", - "Decentralization", - "cybernetics", - "DAO", - "Decentralization", - "Governance" - ], - "keywords": [ - "Cryptolaw", - "cybernetics" - ], - "duration": 1641, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "2pYy07uUG4c", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324013a168eb5355d6509.vtt", - "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY", - "resources_slides": null, "speakers": [ - "gabriel-shapiro" - ] + "vitalik-buterin", + "eli-dourado" + ], + "eventId": "devcon-7", + "slot_start": 1731582600000, + "slot_end": 1731584400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s" }, "vector": [ 0, + 6, 0, 0, 0, @@ -189910,9 +190053,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -190095,6 +190235,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -190733,13 +190874,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -190876,7 +191014,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -191199,11 +191336,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -191216,51 +191358,52 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "daos-unmasked-the-hard-truths-behind-the-hype", - "sourceId": "ZSSKBL", - "title": "DAOs Unmasked: The Hard Truths Behind the Hype", - "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!", + "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds", + "sourceId": "3E7R7G", + "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds", + "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.", "track": "Coordination", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "tags": [ - "Coordination", "DAO", "Governance", - "Regulation", - "Coordination", + "Decentralization", + "cybernetics", "DAO", + "Decentralization", "Governance" ], "keywords": [ - "Decentralization Theater", - "Regulation" + "Cryptolaw", + "cybernetics" ], - "duration": 1670, + "duration": 1641, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "pdlMrmUxpSg", + "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012", + "sources_youtubeId": "2pYy07uUG4c", "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/673324013a168eb5355d6509.vtt", + "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel", "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731394800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k", + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY", "resources_slides": null, "speakers": [ - "lefteris-karapetsas" + "gabriel-shapiro" ] }, "vector": [ @@ -191478,7 +191621,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -192098,18 +192240,20 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, 0, 0, 2, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -192157,7 +192301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -192243,6 +192386,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -192564,16 +192708,16 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -192586,45 +192730,53 @@ }, { "session": { - "id": "dare-to-be-solo-staking", - "sourceId": "ZMSNHW", - "title": "Dare to be Solo Staking", - "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.", - "track": "Core Protocol", - "type": "Lightning Talk", + "id": "daos-unmasked-the-hard-truths-behind-the-hype", + "sourceId": "ZSSKBL", + "title": "DAOs Unmasked: The Hard Truths Behind the Hype", + "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "staking" - ], "tags": [ - "Staking", - "Home staking", - "Best Practices", - "Public good", - "Best Practices", - "Home staking", - "Public good" + "Coordination", + "DAO", + "Governance", + "Regulation", + "Coordination", + "DAO", + "Governance" ], - "language": "en", - "speakers": [ - "jerome-de-tychey" + "keywords": [ + "Decentralization Theater", + "Regulation" ], + "duration": 1670, + "language": "en", + "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c", + "sources_youtubeId": "pdlMrmUxpSg", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731642600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8" + "slot_start": 1731393000000, + "slot_end": 1731394800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k", + "resources_slides": null, + "speakers": [ + "lefteris-karapetsas" + ] }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -192632,6 +192784,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -193388,7 +193541,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -193443,7 +193595,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -193457,10 +193608,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -193486,7 +193639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -193515,6 +193667,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -193941,54 +194096,44 @@ }, { "session": { - "id": "dark-daos-and-private-coordination", - "sourceId": "SX8B9E", - "title": "Dark DAOs and Private Coordination", - "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "dare-to-be-solo-staking", + "sourceId": "ZMSNHW", + "title": "Dare to be Solo Staking", + "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Coordination", - "DAO", - "Privacy", - "dark", - "Coordination", - "DAO", - "Privacy" - ], "keywords": [ - "encumbrance", - "TEE", - "Dark DAO" + "staking" + ], + "tags": [ + "Staking", + "Home staking", + "Best Practices", + "Public good", + "Best Practices", + "Home staking", + "Public good" ], - "duration": 1515, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "iU-2dwVVagk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt", - "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY", - "resources_slides": null, "speakers": [ - "sarah-allen" - ] + "jerome-de-tychey" + ], + "eventId": "devcon-7", + "slot_start": 1731642000000, + "slot_end": 1731642600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -193996,8 +194141,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -194756,6 +194899,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -194802,6 +194954,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -194840,6 +194993,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -194878,7 +195035,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -194963,61 +195119,52 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -195290,11 +195437,9 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, + 2, 0, 0, 0, @@ -195307,37 +195452,50 @@ }, { "session": { - "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat", - "sourceId": "7QAKPP", - "title": "Dark winter: why the risk of unnatural pandemics is an existential threat", - "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "id": "dark-daos-and-private-coordination", + "sourceId": "SX8B9E", + "title": "Dark DAOs and Private Coordination", + "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Biosafety" - ], "tags": [ - "Collective Intelligence", - "Public good", - "Security" + "Coordination", + "DAO", + "Privacy", + "dark", + "Coordination", + "DAO", + "Privacy" ], - "language": "en", - "speakers": [ - "raina-macintyre" + "keywords": [ + "encumbrance", + "TEE", + "Dark DAO" ], + "duration": 1515, + "language": "en", + "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e", + "sources_youtubeId": "iU-2dwVVagk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt", + "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.", "eventId": "devcon-7", - "slot_start": 1731568500000, - "slot_end": 1731569400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU" + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY", + "resources_slides": null, + "speakers": [ + "sarah-allen" + ] }, "vector": [ - 0, - 6, 0, 0, 0, @@ -195349,6 +195507,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -196074,8 +196233,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -196108,7 +196265,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -196180,10 +196336,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -196196,6 +196352,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -196233,6 +196390,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -196318,6 +196476,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -196640,10 +196799,12 @@ 0, 2, 0, - 2, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -196658,47 +196819,41 @@ }, { "session": { - "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society", - "sourceId": "FKED87", - "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.", - "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!", - "track": "Cypherpunk & Privacy", - "type": "Talk", + "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat", + "sourceId": "7QAKPP", + "title": "Dark winter: why the risk of unnatural pandemics is an existential threat", + "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "crypto-anarchy", - "agorism" + "Biosafety" ], "tags": [ - "Privacy", - "Anonymity", - "ZKP", - "agorism", - "Anonymity", - "Privacy", - "ZKP" + "Collective Intelligence", + "Public good", + "Security" ], "language": "en", "speakers": [ - "amir-taaki" + "raina-macintyre" ], "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731491400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE" + "slot_start": 1731568500000, + "slot_end": 1731569400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU" }, "vector": [ 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -197432,6 +197587,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -197456,7 +197612,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -197466,6 +197621,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -197505,7 +197661,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -197541,13 +197696,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -197671,7 +197829,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -197996,12 +198153,12 @@ 0, 2, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -198014,37 +198171,43 @@ }, { "session": { - "id": "data-driven-tokenomics-analyzing-incentives-in-action", - "sourceId": "LPDCMK", - "title": "Data-Driven Tokenomics: Analyzing Incentives in Action", - "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", + "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society", + "sourceId": "FKED87", + "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.", + "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!", + "track": "Cypherpunk & Privacy", + "type": "Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "data analytics", - "growth analytics", - "user behaviour" + "crypto-anarchy", + "agorism" ], "tags": [ - "macro/micro economics", - "Tokenomics", - "User Research" + "Privacy", + "Anonymity", + "ZKP", + "agorism", + "Anonymity", + "Privacy", + "ZKP" ], "language": "en", "speakers": [ - "lisa-jy-tan" + "amir-taaki" ], "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731484800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU" + "slot_start": 1731490200000, + "slot_end": 1731491400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE" }, "vector": [ + 0, + 0, + 0, 0, 0, 6, @@ -198261,11 +198424,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -198806,6 +198970,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -198827,7 +198992,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -198855,6 +199019,17 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -198870,7 +199045,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -198887,6 +199061,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -199318,43 +199508,14 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -199367,46 +199528,40 @@ }, { "session": { - "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations", - "sourceId": "LVVTKU", - "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations", - "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality", - "track": "Security", + "id": "data-driven-tokenomics-analyzing-incentives-in-action", + "sourceId": "LPDCMK", + "title": "Data-Driven Tokenomics: Analyzing Incentives in Action", + "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.", + "track": "Cryptoeconomics", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Tooling", - "debugging", - "testing" + "data analytics", + "growth analytics", + "user behaviour" ], "tags": [ - "DevEx", - "Security", - "Best Practices", - "Testing", - "Best Practices", - "DevEx", - "Security", - "Testing" + "macro/micro economics", + "Tokenomics", + "User Research" ], "language": "en", "speakers": [ - "aellison-cassimiro" + "lisa-jy-tan" ], "eventId": "devcon-7", - "slot_start": 1731656400000, - "slot_end": 1731657000000, + "slot_start": 1731484200000, + "slot_end": 1731484800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM" + "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU" }, "vector": [ - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -200141,7 +200296,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -200171,8 +200325,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -200190,6 +200342,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -200232,6 +200385,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -200359,6 +200513,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -200383,7 +200538,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -200703,7 +200857,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -200715,6 +200868,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -200725,44 +200882,46 @@ }, { "session": { - "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status", - "sourceId": "JLWSZ7", - "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status", - "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", + "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations", + "sourceId": "LVVTKU", + "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations", + "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Debugging" + "Tooling", + "debugging", + "testing" ], "tags": [ - "Developer Infrastructure", - "Tooling", + "DevEx", + "Security", "Best Practices", - "debugging", + "Testing", "Best Practices", - "Developer Infrastructure", - "Tooling" + "DevEx", + "Security", + "Testing" ], "language": "en", "speakers": [ - "g-nick-gnidan" + "aellison-cassimiro" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU" + "slot_start": 1731656400000, + "slot_end": 1731657000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM" }, "vector": [ + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -201498,6 +201657,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -201517,7 +201677,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -201527,6 +201686,8 @@ 0, 0, 0, + 0, + 2, 2, 0, 0, @@ -201550,7 +201711,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -202058,13 +202219,13 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, - 2, 0, 0, + 2, 0, 0, 0, @@ -202080,49 +202241,46 @@ }, { "session": { - "id": "debunking-myths-about-building-out-of-sea", - "sourceId": "CDVQ7R", - "title": "Debunking Myths about Building out of SEA", - "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Local/SEA", + "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status", + "sourceId": "JLWSZ7", + "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status", + "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Build", - "Myth", - "Local" + "Debugging" ], "tags": [ - "Local Impact", - "SEA", - "myths", - "SEA" + "Developer Infrastructure", + "Tooling", + "Best Practices", + "debugging", + "Best Practices", + "Developer Infrastructure", + "Tooling" ], "language": "en", "speakers": [ - "matthew-tan", - "harith-kamarul", - "tn-lee", - "loi-luu" + "g-nick-gnidan" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731650400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY" + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -202339,9 +202497,6 @@ 0, 0, 6, - 6, - 6, - 6, 0, 0, 0, @@ -202879,6 +203034,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -202888,6 +203044,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -202910,6 +203067,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -203097,8 +203257,6 @@ 0, 0, 0, - 2, - 2, 2, 0, 0, @@ -203417,10 +203575,13 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -203431,31 +203592,44 @@ 0, 0, 0, - 2, 0 ] }, { "session": { - "id": "deca-12x", - "sourceId": "WYESYA", - "title": "Deca 12x", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "debunking-myths-about-building-out-of-sea", + "sourceId": "CDVQ7R", + "title": "Debunking Myths about Building out of SEA", + "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Local/SEA", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Build", + "Myth", + "Local" + ], + "tags": [ + "Local Impact", + "SEA", + "myths", + "SEA" + ], "language": "en", - "speakers": [], + "speakers": [ + "matthew-tan", + "harith-kamarul", + "tn-lee", + "loi-luu" + ], "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I" + "slot_start": 1731646800000, + "slot_end": 1731650400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY" }, "vector": [ 0, @@ -203464,9 +203638,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -203684,6 +203855,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -204441,8 +204616,9 @@ 0, 0, 0, - 0, - 0, + 2, + 2, + 2, 0, 0, 0, @@ -204762,8 +204938,6 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, @@ -204775,43 +204949,31 @@ 0, 0, 0, + 2, 0 ] }, { "session": { - "id": "decentralize-your-sequencer-a-guide-for-l2s", - "sourceId": "BNBCVC", - "title": "Decentralize your sequencer -- A guide for L2’s", - "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", + "id": "deca-12x", + "sourceId": "WYESYA", + "title": "Deca 12x", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Sequencer", - "Decentralisation" - ], - "tags": [ - "Zk Rollups", - "Sufficient decentralization", - "Decentralization", - "sequencer", - "Decentralization", - "Sufficient decentralization", - "Zk Rollups" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "joe-andrews" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M" + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I" }, "vector": [ 0, @@ -204821,6 +204983,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -205041,7 +205205,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -205621,7 +205784,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -205654,7 +205816,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -205665,7 +205826,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -205709,7 +205869,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -206114,10 +206273,14 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -206136,37 +206299,38 @@ }, { "session": { - "id": "decentralized-outcome-funding-for-investigative-reporters", - "sourceId": "SJE7VP", - "title": "Decentralized Outcome Funding for Investigative Reporters", - "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.", - "track": "Real World Ethereum", + "id": "decentralize-your-sequencer-a-guide-for-l2s", + "sourceId": "BNBCVC", + "title": "Decentralize your sequencer -- A guide for L2’s", + "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Hypercerts" + "Sequencer", + "Decentralisation" ], "tags": [ - "Effective Altruism", - "Ethereum for Good", - "Regenerative Applications", - "hypercerts", - "Effective Altruism", - "Ethereum for Good", - "Regenerative Applications" + "Zk Rollups", + "Sufficient decentralization", + "Decentralization", + "sequencer", + "Decentralization", + "Sufficient decentralization", + "Zk Rollups" ], "language": "en", "speakers": [ - "devansh-mehta" + "joe-andrews" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731467700000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg" + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M" }, "vector": [ 0, @@ -206175,9 +206339,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -206978,6 +207141,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207010,6 +207174,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207020,6 +207185,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207033,12 +207199,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -207065,6 +207229,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207097,7 +207262,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207154,7 +207318,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207475,9 +207638,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -207491,45 +207656,46 @@ }, { "session": { - "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks", - "sourceId": "NWSNWX", - "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks", - "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.", - "track": "Core Protocol", + "id": "decentralized-outcome-funding-for-investigative-reporters", + "sourceId": "SJE7VP", + "title": "Decentralized Outcome Funding for Investigative Reporters", + "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.", + "track": "Real World Ethereum", "type": "Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "EIP 4444s", - "Portal Network", - "Decentralization" + "Hypercerts" ], "tags": [ - "Decentralization", - "Decentralization", - "Light Clients" + "Effective Altruism", + "Ethereum for Good", + "Regenerative Applications", + "hypercerts", + "Effective Altruism", + "Ethereum for Good", + "Regenerative Applications" ], "language": "en", "speakers": [ - "kolby-moroz-liebl" + "devansh-mehta" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk" + "slot_start": 1731465900000, + "slot_end": 1731467700000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -208280,7 +208446,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -208362,7 +208527,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -208390,10 +208554,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -208452,6 +208618,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -208509,6 +208676,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -208826,11 +208994,11 @@ 0, 2, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -208844,39 +209012,41 @@ }, { "session": { - "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy", - "sourceId": "STX9DW", - "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy", - "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state", - "track": "Real World Ethereum", + "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks", + "sourceId": "NWSNWX", + "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks", + "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "EIP 4444s", + "Portal Network", + "Decentralization" + ], "tags": [ "Decentralization", - "Ethereum for Good", - "Network State" + "Decentralization", + "Light Clients" ], "language": "en", "speakers": [ - "joe-lubin" + "kolby-moroz-liebl" ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4" + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk" }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -209101,6 +209271,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -209631,6 +209802,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -209656,7 +209830,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -209735,7 +209908,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -210171,12 +210343,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -210193,40 +210366,31 @@ }, { "session": { - "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya", - "sourceId": "SRYTXY", - "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya", - "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.", + "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy", + "sourceId": "STX9DW", + "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy", + "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state", "track": "Real World Ethereum", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ReFi", - "Emerging Markets" - ], + "keywords": [], "tags": [ - "Use Cases", - "Ethereum for Good", - "Local Impact", - "market", - "emerging", + "Decentralization", "Ethereum for Good", - "Local Impact", - "Use Cases" + "Network State" ], "language": "en", "speakers": [ - "anna-stone", - "damaris-njoroge" + "joe-lubin" ], "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, + "slot_start": 1731580200000, + "slot_end": 1731582000000, "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ" + "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4" }, "vector": [ 0, @@ -210459,8 +210623,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -211003,7 +211165,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -211018,6 +211179,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -211046,7 +211209,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -211072,6 +211234,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -211211,14 +211376,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -211531,6 +211688,16 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -211538,8 +211705,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -211551,39 +211716,40 @@ }, { "session": { - "id": "decentralizing-the-internets-collaboration-layer", - "sourceId": "NZMSMG", - "title": "Decentralizing the Internet's collaboration layer", - "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.", + "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya", + "sourceId": "SRYTXY", + "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya", + "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.", "track": "Real World Ethereum", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "mutual", - "aid" + "ReFi", + "Emerging Markets" ], "tags": [ - "Coordination", - "Privacy", "Use Cases", - "mutual", - "aid", - "Coordination", - "Privacy", + "Ethereum for Good", + "Local Impact", + "market", + "emerging", + "Ethereum for Good", + "Local Impact", "Use Cases" ], "language": "en", "speakers": [ - "andreas-tsamados" + "anna-stone", + "damaris-njoroge" ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556200000, + "slot_start": 1731409200000, + "slot_end": 1731411000000, "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw" + "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ" }, "vector": [ 0, @@ -211817,8 +211983,7 @@ 0, 0, 0, - 0, - 0, + 6, 6, 0, 0, @@ -212362,6 +212527,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -212441,7 +212608,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212451,6 +212617,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -212479,7 +212646,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212570,11 +212736,11 @@ 0, 0, 0, + 2, 0, 0, 0, 2, - 2, 0, 0, 0, @@ -212886,10 +213052,11 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -212908,30 +213075,39 @@ }, { "session": { - "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1", - "sourceId": "ZAKUY3", - "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1", - "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Expert", - "audience": "Engineering", + "id": "decentralizing-the-internets-collaboration-layer", + "sourceId": "NZMSMG", + "title": "Decentralizing the Internet's collaboration layer", + "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "mutual", + "aid" + ], + "tags": [ + "Coordination", + "Privacy", + "Use Cases", + "mutual", + "aid", + "Coordination", + "Privacy", + "Use Cases" + ], "language": "en", "speakers": [ - "julien", - "grant-southey", - "gregskrileth", - "thomas-clowes" + "andreas-tsamados" ], "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731486600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ" + "slot_start": 1731555000000, + "slot_end": 1731556200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw" }, "vector": [ 0, @@ -212940,7 +213116,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -213169,9 +213344,6 @@ 0, 0, 6, - 6, - 6, - 6, 0, 0, 0, @@ -213756,6 +213928,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -213793,6 +213966,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -213830,6 +214004,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -213924,6 +214099,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -214234,16 +214411,16 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -214256,41 +214433,32 @@ }, { "session": { - "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients", - "sourceId": "D3XZKF", - "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients", - "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", + "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1", + "sourceId": "ZAKUY3", + "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1", + "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Fork choice", - "model based testing", - "fuzz testing" - ], - "tags": [ - "Core Protocol", - "Fuzzing", - "Testing", - "Core Protocol", - "Testing" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "mikhail-kalinin", - "alex-vlasov" + "julien", + "grant-southey", + "gregskrileth", + "thomas-clowes" ], "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731580200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q" + "slot_start": 1731481200000, + "slot_end": 1731486600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ" }, "vector": [ - 6, 0, 0, 0, @@ -214298,6 +214466,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -214523,13 +214693,16 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 0, 0, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -215029,7 +215202,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -215047,7 +215219,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -215270,7 +215441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -215590,11 +215760,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -215612,43 +215782,40 @@ }, { "session": { - "id": "deep-dive-the-lp-pricing", - "sourceId": "CDPRCK", - "title": "Deep Dive the LP Pricing", - "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Expert", + "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients", + "sourceId": "D3XZKF", + "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients", + "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Math", - "Oracle price", - "DeFi" + "Fork choice", + "model based testing", + "fuzz testing" ], "tags": [ - "Security", - "Mechanism design", - "Economics", - "defi", - "Economics", - "Mechanism design", - "Security" + "Core Protocol", + "Fuzzing", + "Testing", + "Core Protocol", + "Testing" ], "language": "en", "speakers": [ - "nipun-pitimanaaree" + "mikhail-kalinin", + "alex-vlasov" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8" + "slot_start": 1731578400000, + "slot_end": 1731580200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q" }, "vector": [ - 0, - 0, 6, 0, 0, @@ -215888,6 +216055,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -216385,10 +216553,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -216410,16 +216574,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -216578,29 +216732,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, @@ -216667,6 +216798,42 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -216951,6 +217118,9 @@ 0, 0, 2, + 0, + 0, + 0, 2, 0, 0, @@ -216969,43 +217139,43 @@ }, { "session": { - "id": "defcon-at-devcon-a-table-top-experience", - "sourceId": "P9DRXY", - "title": "Defcon at Devcon: A table top experience", - "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.", - "track": "Security", - "type": "Workshop", - "expertise": "Intermediate", + "id": "deep-dive-the-lp-pricing", + "sourceId": "CDPRCK", + "title": "Deep Dive the LP Pricing", + "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Tabletop", - "Incident Response", - "Threat Intelligence" + "Math", + "Oracle price", + "DeFi" ], "tags": [ - "Best Practices", - "Hacks", - "Event monitoring", - "threat", - "intelligence", - "Best Practices", - "Event monitoring", - "Hacks" + "Security", + "Mechanism design", + "Economics", + "defi", + "Economics", + "Mechanism design", + "Security" ], "language": "en", "speakers": [ - "heidi-wilder", - "peter-kacherginsky" + "nipun-pitimanaaree" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731645900000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0" + "slot_start": 1731488400000, + "slot_end": 1731489000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8" }, "vector": [ + 0, + 0, 6, 0, 0, @@ -217244,11 +217414,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -217744,12 +217913,14 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -217775,9 +217946,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -217935,6 +218106,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -217995,10 +218168,6 @@ 0, 0, 0, - 2, - 2, - 2, - 2, 0, 0, 0, @@ -218306,11 +218475,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -218328,34 +218497,41 @@ }, { "session": { - "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind", - "sourceId": "9KWRRJ", - "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind", - "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.", + "id": "defcon-at-devcon-a-table-top-experience", + "sourceId": "P9DRXY", + "title": "Defcon at Devcon: A table top experience", + "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.", "track": "Security", - "type": "Lightning Talk", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Clear signing", - "transactions" + "Tabletop", + "Incident Response", + "Threat Intelligence" ], "tags": [ - "Open Source Software", - "Security", - "UI/UX" + "Best Practices", + "Hacks", + "Event monitoring", + "threat", + "intelligence", + "Best Practices", + "Event monitoring", + "Hacks" ], "language": "en", "speakers": [ - "charles-guillemet" + "heidi-wilder", + "peter-kacherginsky" ], "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731409800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg" + "slot_start": 1731638700000, + "slot_end": 1731645900000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0" }, "vector": [ 6, @@ -218599,8 +218775,7 @@ 0, 0, 0, - 0, - 0, + 6, 6, 0, 0, @@ -219096,7 +219271,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -219130,6 +219304,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -219155,7 +219330,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -219194,7 +219368,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -219352,6 +219525,10 @@ 0, 0, 0, + 2, + 2, + 2, + 2, 0, 0, 0, @@ -219662,9 +219839,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -219680,35 +219857,37 @@ }, { "session": { - "id": "defragmenting-ethereum-interoperability-and-the-superchain", - "sourceId": "YEQLR8", - "title": "Defragmenting Ethereum - Interoperability and the Superchain", - "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?", - "track": "Layer 2", - "type": "Talk", + "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind", + "sourceId": "9KWRRJ", + "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind", + "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.", + "track": "Security", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "superchain", - "OP Stack", - "optimism" + "Clear signing", + "transactions" ], "tags": [ - "optimism" + "Open Source Software", + "Security", + "UI/UX" ], "language": "en", "speakers": [ - "karl-floersch" + "charles-guillemet" ], "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA" + "slot_start": 1731409200000, + "slot_end": 1731409800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg" }, "vector": [ + 6, 0, 0, 0, @@ -219716,8 +219895,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -220449,6 +220626,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -220507,6 +220685,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -220545,6 +220724,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -220702,7 +220882,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -221013,9 +221192,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -221031,43 +221210,33 @@ }, { "session": { - "id": "degen-incentives-for-regen-outcomes", - "sourceId": "MNWVFW", - "title": "Degen incentives for Regen outcomes", - "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.", - "track": "Coordination", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "id": "defragmenting-ethereum-interoperability-and-the-superchain", + "sourceId": "YEQLR8", + "title": "Defragmenting Ethereum - Interoperability and the Superchain", + "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Ethereum Culture", - "Ethereum Community", - "degens🤝regens" + "superchain", + "OP Stack", + "optimism" ], "tags": [ - "Ethereum for Good", - "Regenerative Applications", - "Product-market fit", - "regen", - "degens", - "Ethereum for Good", - "Product-market fit", - "Regenerative Applications" + "optimism" ], "language": "en", "speakers": [ - "griff-green", - "nico-gallardo", - "james-kiernan", - "lauren-luz" + "karl-floersch" ], "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731646800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA" + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA" }, "vector": [ 0, @@ -221077,12 +221246,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -221316,9 +221484,6 @@ 0, 0, 6, - 6, - 6, - 6, 0, 0, 0, @@ -221866,7 +222031,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -221934,12 +222098,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -222064,8 +222226,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -222074,6 +222234,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -222376,10 +222544,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -222392,40 +222562,45 @@ }, { "session": { - "id": "demand-based-recurring-fees-in-practice", - "sourceId": "GWBWPE", - "title": "Demand-based recurring fees in practice", - "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "degen-incentives-for-regen-outcomes", + "sourceId": "MNWVFW", + "title": "Degen incentives for Regen outcomes", + "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.", + "track": "Coordination", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "pricing" + "Ethereum Culture", + "Ethereum Community", + "degens🤝regens" ], "tags": [ - "Economics", - "Mechanism design", - "Quadratic Voting" + "Ethereum for Good", + "Regenerative Applications", + "Product-market fit", + "regen", + "degens", + "Ethereum for Good", + "Product-market fit", + "Regenerative Applications" ], "language": "en", "speakers": [ - "timdaub" + "griff-green", + "nico-gallardo", + "james-kiernan", + "lauren-luz" ], "eventId": "devcon-7", - "slot_start": 1731495000000, - "slot_end": 1731496800000, + "slot_start": 1731643200000, + "slot_end": 1731646800000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU" + "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA" }, "vector": [ - 0, - 0, - 6, - 0, - 0, 0, 0, 0, @@ -222437,6 +222612,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -222671,6 +222847,9 @@ 0, 0, 6, + 6, + 6, + 6, 0, 0, 0, @@ -223166,8 +223345,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -223194,7 +223371,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -223222,6 +223398,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -223289,10 +223466,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -223368,7 +223547,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -223419,6 +223597,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -223721,7 +223901,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -223732,6 +223911,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -223743,53 +223924,37 @@ }, { "session": { - "id": "demystifying-smart-contract-security-facts-and-fallacies", - "sourceId": "VXRSPU", - "title": "Demystifying Smart Contract Security: Facts & Fallacies", - "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.", - "track": "Security", - "type": "Panel", + "id": "demand-based-recurring-fees-in-practice", + "sourceId": "GWBWPE", + "title": "Demand-based recurring fees in practice", + "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Smart", - "Contract", - "Security" + "pricing" ], "tags": [ - "Security", - "Best Practices", - "Hacks", - "Formal Verification", - "Auditing", - "Bounties", - "smart", - "contracts", - "Auditing", - "Best Practices", - "Bounties", - "Formal Verification", - "Hacks", - "Security" + "Economics", + "Mechanism design", + "Quadratic Voting" ], "language": "en", "speakers": [ - "josselin-feist", - "0xrajeev", - "matthias-egli", - "mehdi-zerouali", - "mooly-sagiv", - "harikrishnan-mulackal" + "timdaub" ], "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731661200000, + "slot_start": 1731495000000, + "slot_end": 1731496800000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g" + "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU" }, "vector": [ + 0, + 0, 6, 0, 0, @@ -224037,15 +224202,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -224528,7 +224688,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -224540,6 +224699,15 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -224680,7 +224848,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -224725,7 +224892,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -224737,6 +224903,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -224779,16 +224947,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -225094,9 +225258,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -225112,39 +225276,53 @@ }, { "session": { - "id": "demystifying-solo-staking-struggles", - "sourceId": "9KV8UQ", - "title": "Demystifying solo staking struggles", - "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", + "id": "demystifying-smart-contract-security-facts-and-fallacies", + "sourceId": "VXRSPU", + "title": "Demystifying Smart Contract Security: Facts & Fallacies", + "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.", + "track": "Security", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "beginners" + "Smart", + "Contract", + "Security" ], "tags": [ + "Security", "Best Practices", - "Home staking", - "Staking" + "Hacks", + "Formal Verification", + "Auditing", + "Bounties", + "smart", + "contracts", + "Auditing", + "Best Practices", + "Bounties", + "Formal Verification", + "Hacks", + "Security" ], "language": "en", "speakers": [ - "remy-roy" + "josselin-feist", + "0xrajeev", + "matthias-egli", + "mehdi-zerouali", + "mooly-sagiv", + "harikrishnan-mulackal" ], "eventId": "devcon-7", - "slot_start": 1731642600000, - "slot_end": 1731643200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10" + "slot_start": 1731657600000, + "slot_end": 1731661200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g" }, "vector": [ - 0, - 0, - 0, - 0, 6, 0, 0, @@ -225395,8 +225573,11 @@ 0, 0, 0, - 0, - 0, + 6, + 6, + 6, + 6, + 6, 6, 0, 0, @@ -225881,50 +226062,7 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 6, 0, 0, 0, @@ -225955,6 +226093,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -225965,7 +226104,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226008,7 +226146,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226077,6 +226214,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -226123,6 +226261,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -226175,6 +226314,38 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 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, @@ -226443,7 +226614,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226451,6 +226621,15 @@ 0, 0, 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -226458,57 +226637,48 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "depin-pushing-decentralization-beyond-blockchain", - "sourceId": "Q8QPSF", - "title": "DePIN: Pushing Decentralization Beyond Blockchain", - "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join", - "track": "Real World Ethereum", + "id": "demystifying-solo-staking-struggles", + "sourceId": "9KV8UQ", + "title": "Demystifying solo staking struggles", + "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.", + "track": "Core Protocol", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", + "expertise": "Beginner", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Distributed Systems", - "Physical Infrastructure", - "Real Time Communication (RTC)" + "beginners" ], "tags": [ - "Architecture", - "Decentralization", - "DePIN", - "Tokenomics", - "communication", - "real", - "time", - "rtc", - "Architecture", - "Decentralization", - "DePIN", - "Tokenomics" + "Best Practices", + "Home staking", + "Staking" ], "language": "en", "speakers": [ - "akshit-gupta" + "remy-roy" ], "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, + "slot_start": 1731642600000, + "slot_end": 1731643200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY" + "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10" }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -226760,6 +226930,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -227263,7 +227434,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227275,6 +227445,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -227285,7 +227457,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227303,7 +227474,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227330,6 +227500,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -227343,7 +227514,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227373,6 +227543,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -227502,9 +227675,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -227803,7 +227973,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227817,6 +227986,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -227825,33 +227998,44 @@ }, { "session": { - "id": "desci-co-designing-the-future-of-science", - "sourceId": "DCHCYW", - "title": "DeSci: Co-Designing The Future of Science", - "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!", + "id": "depin-pushing-decentralization-beyond-blockchain", + "sourceId": "Q8QPSF", + "title": "DePIN: Pushing Decentralization Beyond Blockchain", + "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join", "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Academic", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Science" + "Distributed Systems", + "Physical Infrastructure", + "Real Time Communication (RTC)" ], "tags": [ - "science", - "Data Availability", - "DeSci" + "Architecture", + "Decentralization", + "DePIN", + "Tokenomics", + "communication", + "real", + "time", + "rtc", + "Architecture", + "Decentralization", + "DePIN", + "Tokenomics" ], "language": "en", "speakers": [ - "erin-magennis" + "akshit-gupta" ], "eventId": "devcon-7", - "slot_start": 1731659400000, - "slot_end": 1731660000000, + "slot_start": 1731579600000, + "slot_end": 1731580200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo" + "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY" }, "vector": [ 0, @@ -228111,7 +228295,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -228616,6 +228799,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -228637,6 +228821,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -228654,14 +228839,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -228696,6 +228879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -228726,7 +228910,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -228857,6 +229040,8 @@ 0, 0, 2, + 2, + 2, 0, 0, 0, @@ -229160,6 +229345,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -229167,7 +229353,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -229176,37 +229361,33 @@ }, { "session": { - "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science", - "sourceId": "MZ3RLT", - "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?", - "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.", + "id": "desci-co-designing-the-future-of-science", + "sourceId": "DCHCYW", + "title": "DeSci: Co-Designing The Future of Science", + "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!", "track": "Real World Ethereum", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "Impact" + "Science" ], "tags": [ - "Permissionless", - "Use Cases", - "DeSci", - "impact", - "DeSci", - "Permissionless", - "Use Cases" + "science", + "Data Availability", + "DeSci" ], "language": "en", "speakers": [ - "paul-kohlhaas" + "erin-magennis" ], "eventId": "devcon-7", - "slot_start": 1731658800000, - "slot_end": 1731659400000, + "slot_start": 1731659400000, + "slot_end": 1731660000000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU" + "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo" }, "vector": [ 0, @@ -229467,7 +229648,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -230016,6 +230196,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -230026,7 +230209,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -230139,7 +230321,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -230509,12 +230691,11 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -230523,6 +230704,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -230531,41 +230713,37 @@ }, { "session": { - "id": "designing-an-end-to-end-solution-for-based-preconfirmations", - "sourceId": "CRWBCC", - "title": "Designing an End to End Solution for Based Preconfirmations", - "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science", + "sourceId": "MZ3RLT", + "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?", + "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Preconfirmations", - "Based Rollups", - "Based Sequencing" + "Impact" ], "tags": [ - "Layer 2s", - "Rollups", - "User Experience", - "sequencer", - "based", - "Layer 2s", - "Rollups", - "User Experience" + "Permissionless", + "Use Cases", + "DeSci", + "impact", + "DeSci", + "Permissionless", + "Use Cases" ], "language": "en", "speakers": [ - "anshu-jalan", - "ahmad-bitar" + "paul-kohlhaas" ], "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731661200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8" + "slot_start": 1731658800000, + "slot_end": 1731659400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU" }, "vector": [ 0, @@ -230574,7 +230752,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -230829,7 +231006,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -231322,7 +231498,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -231348,10 +231523,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -231372,7 +231545,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -231392,6 +231564,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -231419,7 +231592,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -231447,6 +231619,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -231504,6 +231677,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -231577,6 +231751,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -231868,13 +232046,14 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -231890,44 +232069,41 @@ }, { "session": { - "id": "designing-and-launching-a-retroround-incentivize-what-matters", - "sourceId": "39AVKD", - "title": "Designing and launching a RetroRound - Incentivize what matters", - "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.", - "track": "Coordination", + "id": "designing-an-end-to-end-solution-for-based-preconfirmations", + "sourceId": "CRWBCC", + "title": "Designing an End to End Solution for Based Preconfirmations", + "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.", + "track": "Layer 2", "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Emerging markets", - "Grant Program Design", - "" + "Preconfirmations", + "Based Rollups", + "Based Sequencing" ], "tags": [ - "RPGF", - "Quadratic Voting", - "Public good", - "Design", - "Mechanism design", - "program", - "grants", - "Mechanism design", - "Public good", - "Quadratic Voting", - "RPGF" + "Layer 2s", + "Rollups", + "User Experience", + "sequencer", + "based", + "Layer 2s", + "Rollups", + "User Experience" ], "language": "en", "speakers": [ - "launamu", - "sejal-rekhan" + "anshu-jalan", + "ahmad-bitar" ], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, + "slot_start": 1731655800000, + "slot_end": 1731661200000, "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4" + "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8" }, "vector": [ 0, @@ -231937,13 +232113,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -232671,11 +232845,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -232689,6 +232861,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -232714,8 +232887,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -232736,6 +232911,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -232777,12 +232953,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -232811,7 +232987,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -232877,7 +233052,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -232934,8 +233108,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -233232,10 +233404,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -233247,47 +233419,56 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "designing-conditional-markets-and-futarchy", - "sourceId": "EWJNVJ", - "title": "Designing Conditional Markets and Futarchy", - "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", + "id": "designing-and-launching-a-retroround-incentivize-what-matters", + "sourceId": "39AVKD", + "title": "Designing and launching a RetroRound - Incentivize what matters", + "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.", + "track": "Coordination", + "type": "Workshop", + "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Prediction", - "markets" + "Emerging markets", + "Grant Program Design", + "" ], "tags": [ - "market", - "prediction", - "DAO", - "Futarchy", - "Public good" + "RPGF", + "Quadratic Voting", + "Public good", + "Design", + "Mechanism design", + "program", + "grants", + "Mechanism design", + "Public good", + "Quadratic Voting", + "RPGF" ], "language": "en", "speakers": [ - "kaseth", - "robin-hanson" + "launamu", + "sejal-rekhan" ], "eventId": "devcon-7", - "slot_start": 1731487800000, - "slot_end": 1731489600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c" + "slot_start": 1731571200000, + "slot_end": 1731576600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4" }, "vector": [ - 0, - 0, - 6, 0, 0, 0, @@ -233299,6 +233480,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -234029,9 +234211,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, 0, 0, 0, @@ -234056,11 +234240,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -234124,7 +234305,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234132,12 +234312,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -234170,6 +234351,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -234237,6 +234419,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -234292,6 +234475,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -234585,9 +234770,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -234607,34 +234792,39 @@ }, { "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": "designing-conditional-markets-and-futarchy", + "sourceId": "EWJNVJ", + "title": "Designing Conditional Markets and Futarchy", + "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.", + "track": "Cryptoeconomics", "type": "Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Prediction", + "markets" + ], + "tags": [ + "market", + "prediction", + "DAO", + "Futarchy", + "Public good" + ], "language": "en", "speakers": [ - "skylar-weaver", - "nathan-sexer" + "kaseth", + "robin-hanson" ], "eventId": "devcon-7", - "slot_start": 1731385800000, - "slot_end": 1731388500000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ" + "slot_start": 1731487800000, + "slot_end": 1731489600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c" }, "vector": [ - 0, - 0, - 0, - 0, 0, 0, 6, @@ -234815,8 +235005,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -234897,11 +235085,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -235408,8 +235597,11 @@ 0, 0, 0, + 2, 0, 0, + 2, + 2, 0, 0, 0, @@ -235473,6 +235665,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235480,6 +235673,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235935,13 +236129,14 @@ 2, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -235953,40 +236148,28 @@ }, { "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", + "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ" }, "vector": [ 0, @@ -235995,12 +236178,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -236037,7 +236219,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -236175,6 +236356,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -236738,9 +236920,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -236995,7 +237174,13 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -237292,7 +237477,6 @@ 2, 0, 0, - 0, 2, 0, 0, @@ -237311,31 +237495,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": [], + "keywords": [ + "Folding schemes", + "IVC", + "Nova" + ], "tags": [ - "MPC", - "Privacy", - "Use cases of cryptography" + "Libraries", + "Zero-Knowledge", + "Cryptography", + "nova", + "Cryptography", + "Libraries", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "vivek-bhupatiraju" + "pierre-daix-moreux", + "arnaucube" ], "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" + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1IOfjp_pKz83JTceKqk5Rve7U1YRQJSc4MA5OPmnj6oE" }, "vector": [ 0, @@ -237386,8 +237579,7 @@ 0, 0, 0, - 0, - 0, + 6, 0, 0, 0, @@ -238089,6 +238281,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -238104,7 +238299,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -238165,7 +238359,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -238193,7 +238386,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -238347,6 +238539,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -238638,8 +238831,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -238655,51 +238848,42 @@ 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" - ], + "keywords": [], "tags": [ - "Architecture", - "Tooling", - "DevEx", - "Event monitoring", - "research", - "DevEx", - "Event monitoring", - "Tooling" + "MPC", + "Privacy", + "Use cases of cryptography" ], "language": "en", "speakers": [ - "mateusz-radomski" + "vivek-bhupatiraju" ], "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" }, "vector": [ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -238707,6 +238891,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -239454,7 +239639,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -239495,7 +239680,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -239525,6 +239709,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -239552,6 +239737,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -239685,7 +239874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -239702,7 +239890,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -240000,6 +240187,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240007,7 +240195,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -240017,33 +240204,41 @@ }, { "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, @@ -240313,6 +240508,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -240803,6 +240999,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240811,6 +241008,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240842,6 +241040,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -241032,6 +241231,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -241048,6 +241248,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -241342,7 +241543,6 @@ 2, 0, 0, - 2, 0, 0, 0, @@ -241352,6 +241552,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -241360,9 +241562,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", @@ -241375,10 +241577,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, @@ -242682,6 +242884,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -242703,9 +242906,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", @@ -242718,10 +242921,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, @@ -244025,6 +244228,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -244046,9 +244250,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", @@ -244061,10 +244265,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, @@ -245368,6 +245572,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -245389,27 +245594,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, @@ -245682,35 +245885,37 @@ 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, @@ -246715,14 +246920,13 @@ 2, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -246734,45 +246938,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, - "keywords": [ - "Product Management", - "Strategy", - "Product Discovery" - ], - "tags": [ - "Product-market fit", - "User Experience", - "UI/UX", - "User Research", - "product", - "discovery", - "Product-market fit", - "UI/UX", - "User Experience", - "User Research" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "rahul-rumalla", - "alice-chaverot", - "austin-keeble", - "romina-bungert" + "pino7" ], "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" + "slot_start": 1731564000000, + "slot_end": 1731567600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1FZiG2A1-zzZBVPF6IvnlZPydiJX9JFyp4ngPzFzJTEo" }, "vector": [ 0, @@ -246783,6 +246969,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -247044,12 +247231,11 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -247529,7 +247715,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -247571,8 +247756,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -247600,7 +247783,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -247783,8 +247965,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -248077,7 +248257,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -248092,46 +248271,60 @@ 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" + "Product Management", + "Strategy", + "Product Discovery" ], "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" + "rahul-rumalla", + "alice-chaverot", + "austin-keeble", + "romina-bungert" ], "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" }, "vector": [ - 0, - 0, - 6, - 0, - 0, 0, 0, 0, @@ -248140,6 +248333,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -248403,6 +248597,9 @@ 0, 0, 6, + 6, + 6, + 6, 0, 0, 0, @@ -248883,6 +249080,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -248924,6 +249122,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -248951,9 +249151,7 @@ 0, 0, 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -249138,6 +249336,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -249427,8 +249626,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 2, @@ -249437,6 +249634,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -249449,44 +249648,39 @@ }, { "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": [ - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -249760,19 +249954,6 @@ 0, 0, 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -250221,30 +250402,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, 0, 0, 0, @@ -250494,14 +250651,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -250541,6 +250690,38 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -250783,12 +250964,25 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -250800,43 +250994,45 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "double-entry-point-issues-from-breaking-compound-to-uniswap-v4", - "sourceId": "N9ZSQW", - "title": "Double entry point issues - From breaking Compound to Uniswap v4", - "description": "A short explanation of a critical-severity vulnerability we found in the Uniswap V4 core contracts that would have caused a ~$15M loss in Uniswap's pools. The goal is to explain the risks of double entry points, from the $30M+ TUSD issue in Compound to the Uniswap V4-specific case where protocols use native tokens and operate on chains where the native token has a corresponding ERC-20 token, and how to prevent them.", + "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, @@ -251115,9 +251311,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -251598,6 +251795,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -251639,7 +251839,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -251729,7 +251928,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -251835,7 +252033,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -251851,7 +252048,6 @@ 0, 0, 0, - 2, 2, 0, 0, @@ -252139,13 +252335,14 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -252161,47 +252358,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, @@ -252934,6 +253131,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -252991,10 +253190,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -253041,7 +253240,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253085,6 +253283,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -253141,7 +253340,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253176,7 +253374,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253193,6 +253390,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -253209,6 +253407,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -253494,16 +253693,16 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -253516,39 +253715,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, @@ -253830,7 +254027,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -254339,24 +254535,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, @@ -254396,20 +254574,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -254432,6 +254596,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -254533,6 +254698,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -254598,6 +254764,61 @@ 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, @@ -254830,35 +255051,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, - 2, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -254866,6 +255058,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0 @@ -254873,50 +255071,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": "", - "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, @@ -254925,7 +255112,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -255688,7 +255874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255710,6 +255895,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -255723,7 +255909,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255739,6 +255924,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -255766,6 +255952,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -255831,7 +256020,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255935,7 +256123,6 @@ 0, 0, 0, - 2, 2, 0, 0, @@ -256221,13 +256408,14 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -256241,39 +256429,50 @@ }, { "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, - "keywords": [ - "Business", - "Enterprise", - "Instituional" - ], "tags": [ - "Coordination", - "Vision", - "Use Cases", - "institutional", - "Coordination", - "Use Cases", - "Vision" + "Layer 2s", + "DevRel", + "Best Practices", + "management", + "stakeholder", + "Best Practices", + "DevRel", + "Layer 2s" ], - "language": "en", - "speakers": [ - "karen-scarbrough" + "keywords": [ + "Ecosystem Building", + "Ecosystem Design", + "Developer Experience", + "Stakeholder Management" ], + "duration": 407, + "language": "en", + "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896", + "sources_youtubeId": "xqs8trszoOY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331cf83a168eb5353a19d3.vtt", + "transcript_text": " Hi, good afternoon, guys. So my name is Ngan. I'm the co-founder of Symmetry. I'm also a fellow Thai here. So it's a pleasure for us to welcome you to my home country and my hometown, which is Bangkok. So really excited to be here. So yeah, straight into my talk. So as you can see from the talk title, it's about ecosystem development. So what I do at Symmetry is basically we help change on what more builders and users from Thailand. So I figured this would be a good topic to touch on given DEF CON so what exactly is ecosystem building so ecosystem building is basically a to the marketplace right so side marketplace so when you're building chains you need both barriers and users and you did both at we strategic timings a chain cannot function with one or another", "eventId": "devcon-7", - "slot_start": 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": [ + "nine-arnakorn" + ] }, "vector": [ 0, @@ -256282,9 +256481,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -257047,6 +257245,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257081,6 +257280,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257093,7 +257293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257169,7 +257368,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257190,6 +257388,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257248,7 +257447,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257294,6 +257492,8 @@ 0, 0, 0, + 0, + 2, 2, 0, 0, @@ -257598,41 +257798,39 @@ }, { "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" + "Business", + "Enterprise", + "Instituional" ], "tags": [ - "ZKP", - "Cryptography", - "SNARK", - "zk", - "based", - "pairing", - "Cryptography", - "SNARK", - "ZKP" + "Coordination", + "Vision", + "Use Cases", + "institutional", + "Coordination", + "Use Cases", + "Vision" ], "language": "en", "speakers": [ - "ivo-kubjas" + "karen-scarbrough" ], "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" }, "vector": [ 0, @@ -257641,12 +257839,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -258386,7 +258583,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -258418,7 +258614,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258448,7 +258643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258457,6 +258651,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -258532,6 +258727,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -258612,6 +258808,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -258654,8 +258853,6 @@ 0, 0, 0, - 2, - 2, 2, 0, 0, @@ -258935,7 +259132,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -258944,6 +259141,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -258957,58 +259156,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": "", - "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, @@ -259750,12 +259945,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -259783,6 +259977,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -259812,6 +260007,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -259864,7 +260060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -260020,6 +260215,8 @@ 0, 0, 2, + 2, + 2, 0, 0, 0, @@ -260301,13 +260498,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -260319,43 +260516,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": "", - "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": [ @@ -260527,7 +260724,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -260644,6 +260840,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -261148,7 +261346,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -261227,6 +261424,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -261659,17 +261857,17 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -261681,42 +261879,53 @@ }, { "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, - "keywords": [ - "ePBS", - "EIP-7732" - ], "tags": [ - "Censorship Resistance", - "Consensus", "Core Protocol", - "PBS" + "Account Abstraction", + "eip", + "Account Abstraction", + "Core Protocol" ], - "language": "en", - "speakers": [ - "kira", - "caleb" + "keywords": [ + "EIP" ], + "duration": 1299, + "language": "en", + "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", + "sources_youtubeId": "_k5fKlKBWV4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731476700000, - "slot_end": 1731477600000, - "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": [ + "lightclient" + ] }, "vector": [ 0, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -261728,7 +261937,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -261872,7 +262080,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -261880,6 +262087,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -261998,7 +262207,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -262456,7 +262664,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -262490,7 +262697,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262503,6 +262709,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -262599,7 +262806,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262738,6 +262944,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -263013,11 +263220,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -263035,62 +263242,42 @@ }, { "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", + "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": "Community", - "featured": true, + "audience": "Engineering", + "featured": false, "doNotRecord": false, + "keywords": [ + "ePBS", + "EIP-7732" + ], "tags": [ + "Censorship Resistance", + "Consensus", "Core Protocol", - "ACD", - "Coordination", - "Governance", - "improvement", - "eip", - "processes", - "ACD", - "Coordination", - "Core Protocol", - "Governance" - ], - "keywords": [ - "EIP", - "Process", - "Improvement" + "PBS" ], - "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" - ] + "kira", + "caleb" + ], + "eventId": "devcon-7", + "slot_start": 1731477600000, + "slot_end": 1731478500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM" }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -263102,6 +263289,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -263245,6 +263433,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -263371,7 +263560,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -263830,6 +264018,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -263861,6 +264052,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -263918,7 +264110,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -263970,6 +264161,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -263977,7 +264173,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264107,10 +264302,6 @@ 0, 0, 0, - 2, - 2, - 2, - 2, 0, 0, 0, @@ -264388,12 +264579,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -264406,41 +264597,55 @@ }, { "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", + "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": false, + "featured": true, "doNotRecord": false, - "keywords": [ - "music", - "relaxation", - "fun" - ], "tags": [ - "Art", - "Marketing" + "Core Protocol", + "ACD", + "Coordination", + "Governance", + "improvement", + "eip", + "processes", + "ACD", + "Coordination", + "Core Protocol", + "Governance" ], - "language": "en", - "speakers": [ - "rafamilkz" + "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": 1731574800000, - "slot_end": 1731577500000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/14nyL7Ln8KMC-c1thokTKnggtUR8lxRb5WI3bRH2a-uQ" + "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, - 0, 0, 0, 0, @@ -264724,10 +264929,11 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -265198,6 +265404,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -265274,6 +265481,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -265282,7 +265490,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265333,6 +265540,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -265464,6 +265672,9 @@ 0, 0, 2, + 2, + 2, + 2, 0, 0, 0, @@ -265736,9 +265947,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -265758,48 +265969,34 @@ }, { "session": { - "id": "elliptic-curves-and-snarks-past-present-and-future", - "sourceId": "Y3PMMA", - "title": "Elliptic curves and SNARKs: past, present and future.", - "description": "Elliptic curves are used in many proof systems. Some systems (e.g. Bulletproofs) use plain curves (e.g. ed25519). Some (e.g. Groth16, KZG-PLONK) use pairing-friendly curves (e.g. BLS12-381). Some recursive systems require pairing-friendly 2-cycle (e.g. MNT4/6) or 2-chains (e.g. BLS12-377/BW6-761). Some other recursive/folding systems require plain 2-cycle (e.g. Pasta). In this talk we will go through the difference between these curves and why there isn't a silver bullet curve for all scenarios.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "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, - "tags": [ - "ZKP", - "Cryptography", - "SNARK", - "elliptic", - "curves", - "Cryptography", - "SNARK", - "ZKP" - ], "keywords": [ - "elliptic", - "curves" + "music", + "relaxation", + "fun" + ], + "tags": [ + "Art", + "Marketing" ], - "duration": 1518, "language": "en", - "sources_swarmHash": "", - "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" - ] + "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, @@ -265811,7 +266008,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -266553,7 +266749,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -266615,7 +266810,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266652,6 +266846,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -266821,7 +267020,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266830,7 +267028,6 @@ 0, 0, 0, - 2, 2, 0, 0, @@ -267102,7 +267299,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267113,6 +267309,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -267124,60 +267322,50 @@ }, { "session": { - "id": "embodiment-practice", - "sourceId": "LNF8NE", - "title": "Embodiment Practice", - "description": "By master Zoe\r\n- Gentle guided stretches to connect with the body and open different energy channels\r\n- A blend of embodiment, asana, meditation, breathwork, tapping, and somatics to weave together mind, body, and soul\r\n\r\nNov 13 10:30 - 11:15", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", - "audience": "Hobby", + "id": "elliptic-curves-and-snarks-past-present-and-future", + "sourceId": "Y3PMMA", + "title": "Elliptic curves and SNARKs: past, present and future.", + "description": "Elliptic curves are used in many proof systems. Some systems (e.g. Bulletproofs) use plain curves (e.g. ed25519). Some (e.g. Groth16, KZG-PLONK) use pairing-friendly curves (e.g. BLS12-381). Some recursive systems require pairing-friendly 2-cycle (e.g. MNT4/6) or 2-chains (e.g. BLS12-377/BW6-761). Some other recursive/folding systems require plain 2-cycle (e.g. Pasta). In this talk we will go through the difference between these curves and why there isn't a silver bullet curve for all scenarios.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "tags": [ + "ZKP", + "Cryptography", + "SNARK", + "elliptic", + "curves", + "Cryptography", + "SNARK", + "ZKP" + ], + "keywords": [ + "elliptic", + "curves" + ], + "duration": 1518, "language": "en", - "speakers": [], + "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": 1731468600000, - "slot_end": 1731471300000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg" + "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, - 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, @@ -267188,6 +267376,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267466,6 +267655,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267928,6 +268118,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267989,6 +268180,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -268195,6 +268387,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -268447,7 +268655,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -268456,50 +268663,58 @@ 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": "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", + "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": [ - "EOF" - ], - "tags": [ - "Core Protocol", - "ACD", - "Testing", - "eof", - "ACD", - "Core Protocol", - "Testing" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "hubert-ritzdorf" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731562800000, - "slot_end": 1731563400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/17yJsWv6HioxijpCWnMnLMPeQFMTy_KMomUQHF2n1hS8" + "slot_start": 1731468600000, + "slot_end": 1731471300000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -268790,7 +269005,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -269257,7 +269471,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -269480,7 +269693,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -269524,13 +269736,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -269800,7 +270010,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -269813,6 +270022,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -269822,43 +270033,41 @@ }, { "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", + "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": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "loss versus rebalancing", - "cross-domain arbitrage" + "EOF" ], "tags": [ - "Layer 2s", - "Cross-L2", - "MEV", - "AMMs", - "cross-domain", - "arbitrage", - "AMMs", - "Cross-L2", - "Layer 2s", - "MEV" + "Core Protocol", + "ACD", + "Testing", + "eof", + "ACD", + "Core Protocol", + "Testing" ], "language": "en", "speakers": [ - "elaine-hu" + "hubert-ritzdorf" ], "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731564000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s" + "slot_start": 1731562800000, + "slot_end": 1731563400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/17yJsWv6HioxijpCWnMnLMPeQFMTy_KMomUQHF2n1hS8" }, "vector": [ + 0, + 0, 0, 0, 6, @@ -270147,10 +270356,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -270599,7 +270808,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -270616,6 +270824,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -270663,7 +270872,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270680,7 +270888,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270797,7 +271004,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270842,6 +271048,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -270885,13 +271092,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 2, - 2, 0, 0, 0, @@ -271159,8 +271366,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -271176,55 +271383,49 @@ 0, 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", + "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": [ - "Ethereum Node", - "Tooling", - "Network Access" + "loss versus rebalancing", + "cross-domain arbitrage" ], "tags": [ - "Staking", - "Best Practices", - "Accessibility", - "network", - "access", - "Accessibility", - "Best Practices", - "Staking" + "Layer 2s", + "Cross-L2", + "MEV", + "AMMs", + "cross-domain", + "arbitrage", + "AMMs", + "Cross-L2", + "Layer 2s", + "MEV" ], "language": "en", "speakers": [ - "stefan-kobrc", - "stereum-team", - "david-muhlbacher" + "elaine-hu" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8" + "slot_start": 1731562200000, + "slot_end": 1731564000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 6, @@ -271511,26 +271712,12 @@ 0, 0, 0, - 6, - 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -271980,6 +272167,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -271988,7 +272176,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272017,7 +272204,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272062,30 +272248,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, 2, 0, 0, @@ -272205,6 +272367,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -272252,16 +272415,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -272306,6 +272459,38 @@ 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, @@ -272521,7 +272706,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272529,6 +272713,25 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -272536,44 +272739,54 @@ 0, 0, 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", + "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": "Community", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Anti-Scam" + "Ethereum Node", + "Tooling", + "Network Access" ], "tags": [ - "Public good", - "SEA", - "Security" + "Staking", + "Best Practices", + "Accessibility", + "network", + "access", + "Accessibility", + "Best Practices", + "Staking" ], "language": "en", "speakers": [ - "michelle-shen" + "stefan-kobrc", + "stereum-team", + "david-muhlbacher" ], "eventId": "devcon-7", - "slot_start": 1731579000000, - "slot_end": 1731579600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw" + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8" }, "vector": [ - 0, - 6, - 0, - 0, 0, 0, 0, @@ -272582,6 +272795,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -272866,6 +273080,8 @@ 0, 0, 6, + 6, + 6, 0, 0, 0, @@ -273308,7 +273524,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -273342,6 +273557,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273370,6 +273586,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273397,6 +273614,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273417,7 +273635,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273438,6 +273655,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273553,7 +273771,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273605,6 +273822,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273879,8 +274097,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -273892,38 +274110,40 @@ }, { "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", + "id": "empowering-a-safer-internet-community-driven-scam-reporting-and-prevention-in-thailand", + "sourceId": "FGUAQX", + "title": "Empowering a Safer Internet: community-driven scam reporting and prevention in Thailand\"", + "description": "In today’s digital age, user-driven solutions are vital for online safety. This talk explores Whoscall—a free mobile app trusted by over 17 million users globally, offering call and SMS identification, phishing site scanning, and personal data breach detection—and Thailand’s Scam Alert feature. Both initiatives empower users and promote public-private collaboration in scam prevention.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Stakers/Validators", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Anti-Scam" + ], "tags": [ - "Decentralization", - "Home staking" + "Public good", + "SEA", + "Security" ], "language": "en", "speakers": [ - "diego-losada" + "michelle-shen" ], "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731643800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ" + "slot_start": 1731579000000, + "slot_end": 1731579600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw" }, "vector": [ 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -274658,6 +274878,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -274742,7 +274964,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -274758,7 +274979,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -274767,6 +274987,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -274903,6 +275124,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -275227,7 +275449,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -275235,41 +275456,36 @@ 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.", + "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": "Intermediate", - "audience": "Research", + "expertise": "Beginner", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, - "keywords": [ - "Encrypted", - "Mempool" - ], + "keywords": [], "tags": [ - "encryption", - "mempool", - "Censorship Resistance", - "Core Protocol", - "Cryptography" + "Decentralization", + "Home staking" ], "language": "en", "speakers": [ - "marc-harvey-hill" + "diego-losada" ], "eventId": "devcon-7", - "slot_start": 1731466500000, - "slot_end": 1731467100000, + "slot_start": 1731643200000, + "slot_end": 1731643800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E" + "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ" }, "vector": [ 0, @@ -275568,7 +275784,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -276023,13 +276238,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -276100,6 +276313,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -276114,6 +276329,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -276158,7 +276376,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276306,8 +276523,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -276572,7 +276787,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276585,6 +276799,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -276594,43 +276811,38 @@ }, { "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", + "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": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "ZK", - "Programmable cryptography", - "onchain games" + "Encrypted", + "Mempool" ], "tags": [ - "Gaming", - "Mechanism design", - "Mobile" + "encryption", + "mempool", + "Censorship Resistance", + "Core Protocol", + "Cryptography" ], "language": "en", "speakers": [ - "small-brain" + "marc-harvey-hill" ], "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731479400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1SKERFupONxE6JOQvDC21CI1lz62VYcj5ZdZOGlXcWOg" + "slot_start": 1731466500000, + "slot_end": 1731467100000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -276767,9 +276979,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -276931,6 +277140,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -277370,7 +277580,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -277386,12 +277595,13 @@ 0, 0, 0, - 2, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -277474,7 +277684,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -277521,6 +277730,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -277669,6 +277879,12 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -277925,7 +278141,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -277934,6 +278149,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -277947,25 +278166,35 @@ }, { "session": { - "id": "energy-renewal-sound-healing", - "sourceId": "7DEDKP", - "title": "Energy Renewal (Sound Healing)", - "description": "By master Ice \r\nThis session helps you rest deeply, reset your energy, and find inner peace.\r\n- Recharge and relax with gentle sounds of gongs and bowls\r\n- a short guided meditation. \r\n\r\nNov 14 10:30 -11:15", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", + "id": "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": [], - "tags": [], + "keywords": [ + "ZK", + "Programmable cryptography", + "onchain games" + ], + "tags": [ + "Gaming", + "Mechanism design", + "Mobile" + ], "language": "en", - "speakers": [], + "speakers": [ + "small-brain" + ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731557700000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg" + "slot_start": 1731477600000, + "slot_end": 1731479400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1SKERFupONxE6JOQvDC21CI1lz62VYcj5ZdZOGlXcWOg" }, "vector": [ 0, @@ -277977,12 +278206,8 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, + 6, 0, 0, 0, @@ -278114,6 +278339,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -278717,6 +278943,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -278732,6 +278959,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -278819,6 +279047,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -279272,6 +279501,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -279290,37 +279520,32 @@ }, { "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", + "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": [ - "Fuzzing", - "p2p network" - ], - "tags": [ - "network", - "p2p" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "tim-fan", - "sun-haochen", - "fudong-wu" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731571800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1B-0SsGH9Jbgo3njphxqoa7CInPi0Ftq_r5Ivuuvi8zg" + "slot_start": 1731555000000, + "slot_end": 1731557700000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -279619,9 +279844,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -280147,7 +280369,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -280357,7 +280578,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -280621,9 +280841,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -280643,56 +280864,43 @@ }, { "session": { - "id": "ens-war-stories-securing-web3-from-web2-based-attacks", - "sourceId": "P9U9Q3", - "title": "ENS War Stories: Securing Web3 from Web2-Based Attacks", - "description": "Web3 is not an island. Every day, threat actors try to exploit web2 domains to target web3 entities. This talk recounts ENS' war stories / lessons of battling threats in the DNS, including:\r\n- Detecting early-stage attacks on web3 entities in the DNS\r\n- How we unraveled a campaign of over 2,500+ web2 domains targeting web3 and defi entities \r\n- Legal and technical remedies to combat web2-based threats (and their limitations)\r\n- Why the ecosystem must come together to share intel and resources", - "track": "Security", + "id": "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": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Collective Intelligence", - "Security", - "Best Practices", - "user", - "safety", - "Best Practices", - "Collective Intelligence", - "Security" - ], "keywords": [ - "threat actors", - "legal process", - "user safety" + "Fuzzing", + "p2p network" + ], + "tags": [ + "network", + "p2p" ], - "duration": 781, "language": "en", - "sources_swarmHash": "", - "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" - ] + "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": [ - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -280985,11 +281193,13 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -281426,7 +281636,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -281457,10 +281666,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -281515,6 +281722,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -281726,7 +281934,7 @@ 0, 0, 2, - 2, + 0, 0, 0, 0, @@ -281992,12 +282200,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -282010,39 +282218,52 @@ }, { "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", + "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": "Research", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "Risks" - ], "tags": [ - "Layer 2s", - "Data Availability", + "Collective Intelligence", "Security", - "risk", - "Data Availability", - "Layer 2s", + "Best Practices", + "user", + "safety", + "Best Practices", + "Collective Intelligence", "Security" ], - "language": "en", - "speakers": [ - "vincenzo-furcillo" + "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": 1731654600000, - "slot_end": 1731655200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1fP4Av0dDJM1g4BBb6EB2lsaWqOTPmZK7RkZvBv_vs-w" + "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, @@ -282050,8 +282271,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -282781,6 +283000,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -282812,6 +283033,23 @@ 0, 0, 0, + 2, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -282847,24 +283085,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -283083,6 +283303,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -283348,11 +283569,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -283365,49 +283586,37 @@ }, { "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", + "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": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, + "keywords": [ + "Risks" + ], "tags": [ - "Identity", - "Zero-Knowledge", - "Security", - "zk", - "proof", - "Identity", + "Layer 2s", + "Data Availability", "Security", - "Zero-Knowledge" - ], - "keywords": [ - "Zk", - "Proof" + "risk", + "Data Availability", + "Layer 2s", + "Security" ], - "duration": 1426, "language": "en", - "sources_swarmHash": "", - "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" - ] + "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, @@ -283415,6 +283624,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -283710,11 +283921,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -284160,7 +284370,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -284197,7 +284406,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -284216,6 +284424,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -284372,7 +284583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -284430,7 +284640,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -284451,6 +284660,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -284714,8 +284924,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -284732,38 +284942,49 @@ }, { "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", + "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": "Community", + "audience": "Engineering", "featured": false, - "doNotRecord": true, - "keywords": [ - "Conflict" - ], + "doNotRecord": false, "tags": [ - "Layer 2s", - "Governance", - "Emergency Plan", - "conflict", - "Emergency Plan", - "Governance", - "Layer 2s" + "Identity", + "Zero-Knowledge", + "Security", + "zk", + "proof", + "Identity", + "Security", + "Zero-Knowledge" ], - "language": "en", - "speakers": [ - "juan-carlos-bell-llinas", - "oxytocin" + "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": 1731393000000, - "slot_end": 1731400200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1QJBCSyIk_2YgSpZlJQsuZo3ymwCCG1XhQXN6zxlSBoQ" + "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, @@ -284771,15 +284992,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -285507,6 +285726,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -285517,6 +285738,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -285553,6 +285775,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -285570,7 +285793,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -285600,7 +285822,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -285708,7 +285929,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -285732,6 +285952,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -285787,6 +286009,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -285806,7 +286029,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -286070,12 +286292,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -286088,32 +286310,38 @@ }, { "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", + "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": false, - "keywords": [], + "doNotRecord": true, + "keywords": [ + "Conflict" + ], "tags": [ - "EPF", - "Ethereum Roadmap", - "Layer 1" + "Layer 2s", + "Governance", + "Emergency Plan", + "conflict", + "Emergency Plan", + "Governance", + "Layer 2s" ], "language": "en", "speakers": [ - "mario-havel", - "josh-davis" + "juan-carlos-bell-llinas", + "oxytocin" ], "eventId": "devcon-7", - "slot_start": 1731467700000, - "slot_end": 1731468600000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1UgPaeQAkzm7-SuT2jdxRMLHcVJEzy3CxxHN_BL0ftCg" + "slot_start": 1731393000000, + "slot_end": 1731400200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1QJBCSyIk_2YgSpZlJQsuZo3ymwCCG1XhQXN6zxlSBoQ" }, "vector": [ 0, @@ -286127,13 +286355,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -286869,36 +287095,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -286953,6 +287149,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286982,6 +287179,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -287157,12 +287355,41 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -287425,6 +287652,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -287438,30 +287667,32 @@ }, { "session": { - "id": "epf-day-panel", - "sourceId": "ZMRJ9B", - "title": "EPF Day Panel", - "description": "Panel with former fellows who became core devs and mentors", + "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": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [], + "tags": [ + "EPF", + "Ethereum Roadmap", + "Layer 1" + ], "language": "en", "speakers": [ "mario-havel", - "eniko-nagy", - "echo", - "eitan" + "josh-davis" ], "eventId": "devcon-7", - "slot_start": 1731489300000, - "slot_end": 1731492000000, + "slot_start": 1731467700000, + "slot_end": 1731468600000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk" + "resources_presentation": "https://docs.google.com/presentation/d/1UgPaeQAkzm7-SuT2jdxRMLHcVJEzy3CxxHN_BL0ftCg" }, "vector": [ 0, @@ -287772,9 +288003,6 @@ 0, 0, 6, - 0, - 6, - 6, 6, 0, 0, @@ -288221,6 +288449,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -288399,6 +288628,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -288508,6 +288738,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -288764,7 +288995,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -288775,6 +289005,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -288786,40 +289018,30 @@ }, { "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.", + "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": "Lightning Talk", + "type": "Panel", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Core", - "Protocol" - ], - "keywords": [ - "EVM", - "Optimization" - ], - "duration": 0, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, + "speakers": [ + "mario-havel", + "eniko-nagy", + "echo", + "eitan" + ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731471300000, + "slot_start": 1731489300000, + "slot_end": 1731492000000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/13ze8Pr4OxtxoFIIxGDV0SAGLb_aIJtknEOqxz5Ct5lA", - "resources_slides": null, - "speakers": [ - "siddharth-vaderaa" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk" }, "vector": [ 0, @@ -289129,12 +289351,15 @@ 0, 0, 0, + 6, 0, + 6, + 6, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -289864,8 +290089,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -290144,32 +290367,40 @@ }, { "session": { - "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval", - "sourceId": "FARJAG", - "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval", - "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.", - "track": "Layer 2", - "type": "Talk", + "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, - "keywords": [ - "Cross-chain" - ], "tags": [ - "Layer 2s", - "Zero-Knowledge" + "Core", + "Protocol" ], - "language": "en", - "speakers": [ - "julien" + "keywords": [ + "EVM", + "Optimization" ], + "duration": 0, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc" + "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, @@ -290179,7 +290410,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -290188,6 +290418,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -290406,7 +290638,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -290484,6 +290715,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -290922,7 +291154,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -290976,7 +291207,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -291217,6 +291447,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -291494,37 +291726,32 @@ }, { "session": { - "id": "erc-4337-adoption-analysis", - "sourceId": "SGRFUA", - "title": "ERC-4337: Adoption Analysis", - "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space", - "track": "Usability", + "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval", + "sourceId": "FARJAG", + "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval", + "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": true, + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, "doNotRecord": false, "keywords": [ - "ERC-4337" + "Cross-chain" ], "tags": [ - "DevRel", - "Use Cases", - "Account Abstraction", - "erc-4337", - "Account Abstraction", - "DevRel", - "Use Cases" + "Layer 2s", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "tom-teman" + "julien" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731565800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA" + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc" }, "vector": [ 0, @@ -291534,7 +291761,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -291718,7 +291944,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -291763,6 +291988,22 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -292264,6 +292505,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -292344,7 +292587,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -292428,40 +292670,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -292829,14 +293037,34 @@ 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, - 2, - 0, 0, 0, 0, @@ -292849,50 +293077,48 @@ }, { "session": { - "id": "erigon-3-a-new-paradigm-for-ethereum-clients", - "sourceId": "CWZK8G", - "title": "Erigon 3 a New Paradigm for Ethereum Clients", - "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.", - "track": "Core Protocol", + "id": "erc-4337-adoption-analysis", + "sourceId": "SGRFUA", + "title": "ERC-4337: Adoption Analysis", + "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space", + "track": "Usability", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Product", - "featured": false, + "featured": true, "doNotRecord": false, "keywords": [ - "efficiency", - "client", - "modular" + "ERC-4337" ], "tags": [ - "Architecture", - "Data Availability", - "Scalability", - "modular", - "Architecture", - "Data Availability", - "Scalability" + "DevRel", + "Use Cases", + "Account Abstraction", + "erc-4337", + "Account Abstraction", + "DevRel", + "Use Cases" ], "language": "en", "speakers": [ - "mark-holt" + "tom-teman" ], "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731483000000, + "slot_start": 1731564000000, + "slot_end": 1731565800000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY" + "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -293075,6 +293301,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -293197,7 +293424,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -293674,6 +293900,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -293684,12 +293911,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -293703,6 +293928,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -293762,7 +293988,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -293787,6 +294012,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -293797,6 +294023,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -293928,7 +294156,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -294184,9 +294411,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -294206,48 +294433,39 @@ }, { "session": { - "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power", - "sourceId": "C3HTZP", - "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power", - "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.", + "id": "erigon-3-a-new-paradigm-for-ethereum-clients", + "sourceId": "CWZK8G", + "title": "Erigon 3 a New Paradigm for Ethereum Clients", + "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.", "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Product", "featured": false, "doNotRecord": false, - "tags": [ - "Protocol Design", - "Censorship Resistance", - "Decentralization", - "MEV", - "Censorship Resistance", - "MEV", - "Protocol Design" - ], "keywords": [ - "TEE", - "hardware", - "decentralization" + "efficiency", + "client", + "modular" + ], + "tags": [ + "Architecture", + "Data Availability", + "Scalability", + "modular", + "Architecture", + "Data Availability", + "Scalability" ], - "duration": 1502, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "kSrjley2POk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt", - "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.", - "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js", - "resources_slides": null, "speakers": [ - "philip-daian" - ] + "mark-holt" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731483000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY" }, "vector": [ 0, @@ -294563,7 +294781,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -294990,7 +295207,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -295034,7 +295250,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295054,8 +295269,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, + 2, 0, 0, 0, @@ -295090,7 +295309,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295129,6 +295347,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -295136,7 +295355,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295296,6 +295514,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -295558,7 +295777,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -295567,55 +295785,60 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum", - "sourceId": "TA3N8E", - "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum", - "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power", + "sourceId": "C3HTZP", + "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power", + "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "Ethereum", - "for", - "Good" - ], "tags": [ + "Protocol Design", + "Censorship Resistance", "Decentralization", - "Local Impact", - "Social Recovery", - "ethereum", - "good", - "Decentralization", - "Local Impact", - "Social Recovery" + "MEV", + "Censorship Resistance", + "MEV", + "Protocol Design" ], - "language": "en", - "speakers": [ - "andres-forigua", - "william-martinez", - "mateo-sabogal" + "keywords": [ + "TEE", + "hardware", + "decentralization" ], + "duration": 1502, + "language": "en", + "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11", + "sources_youtubeId": "ySVYt6MUrHM", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt", + "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.", "eventId": "devcon-7", - "slot_start": 1731660600000, - "slot_end": 1731661200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk" + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js", + "resources_slides": null, + "speakers": [ + "philip-daian" + ] }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -295925,9 +296148,8 @@ 0, 0, 0, + 0, 6, - 6, - 6, 0, 0, 0, @@ -296354,6 +296576,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -296395,6 +296620,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -296496,6 +296722,31 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -296516,7 +296767,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -296592,7 +296842,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -296655,29 +296904,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, @@ -296910,9 +297136,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -296932,41 +297158,51 @@ }, { "session": { - "id": "eth-is-permissionless-money", - "sourceId": "TMFPCF", - "title": "ETH is permissionless money", - "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.", - "track": "Cryptoeconomics", - "type": "Talk", + "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum", + "sourceId": "TA3N8E", + "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum", + "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change", + "track": "Real World Ethereum", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Research", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Ethereum", + "for", + "Good" + ], "tags": [ - "Censorship Resistance", "Decentralization", - "Ethereum Roadmap" + "Local Impact", + "Social Recovery", + "ethereum", + "good", + "Decentralization", + "Local Impact", + "Social Recovery" ], "language": "en", "speakers": [ - "mike-neuder" + "andres-forigua", + "william-martinez", + "mateo-sabogal" ], "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY" + "slot_start": 1731660600000, + "slot_end": 1731661200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk" }, "vector": [ 0, 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -297275,9 +297511,11 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -297845,8 +298083,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -297867,6 +298103,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -297934,7 +298171,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -297944,6 +298180,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -298006,6 +298243,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -298264,11 +298502,11 @@ 2, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -298281,50 +298519,40 @@ }, { "session": { - "id": "ethereum-a-force-of-good", - "sourceId": "HUZP7J", - "title": "Ethereum a Force of Good", - "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.", - "track": "Real World Ethereum", + "id": "eth-is-permissionless-money", + "sourceId": "TMFPCF", + "title": "ETH is permissionless money", + "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.", + "track": "Cryptoeconomics", "type": "Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "stablecoins", - "supply chain", - "agriculture", - "scalability" - ], + "keywords": [], "tags": [ - "RWA", - "Ethereum for Good", - "Economics", - "micropayments", - "Economics", - "Ethereum for Good", - "RWA" + "Censorship Resistance", + "Decentralization", + "Ethereum Roadmap" ], "language": "en", "speakers": [ - "stani-kulechov" + "mike-neuder" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, + "slot_start": 1731569400000, + "slot_end": 1731571200000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4" + "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -299090,7 +299318,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299160,6 +299387,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -299181,7 +299409,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299206,10 +299433,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -299252,6 +299479,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -299363,7 +299591,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299619,10 +299846,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 2, @@ -299634,15 +299861,18 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "ethereum-and-robots", - "sourceId": "9G9LSH", - "title": "Ethereum and Robots", - "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware", + "id": "ethereum-a-force-of-good", + "sourceId": "HUZP7J", + "title": "Ethereum a Force of Good", + "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.", "track": "Real World Ethereum", "type": "Talk", "expertise": "Beginner", @@ -299650,28 +299880,29 @@ "featured": false, "doNotRecord": false, "keywords": [ - "Robots" + "stablecoins", + "supply chain", + "agriculture", + "scalability" ], "tags": [ - "Collective Intelligence", - "Civil Resistance", - "DePIN", - "Autonomous World", - "robots", - "Autonomous World", - "Civil Resistance", - "Collective Intelligence", - "DePIN" + "RWA", + "Ethereum for Good", + "Economics", + "micropayments", + "Economics", + "Ethereum for Good", + "RWA" ], "language": "en", "speakers": [ - "tomasz-stanczak" + "stani-kulechov" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, + "slot_start": 1731576600000, + "slot_end": 1731578400000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE" + "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4" }, "vector": [ 0, @@ -299993,7 +300224,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -300434,7 +300664,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300446,11 +300675,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -300522,7 +300753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300540,6 +300770,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -300566,6 +300798,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -300642,7 +300875,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300996,38 +301228,39 @@ }, { "session": { - "id": "ethereum-citizen-embracing-self-sovereign-digital-identity", - "sourceId": "ATKWT8", - "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity", - "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "id": "ethereum-and-robots", + "sourceId": "9G9LSH", + "title": "Ethereum and Robots", + "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Attestations", - "data" + "Robots" ], "tags": [ - "Privacy", - "Identity", - "Social", - "data", - "Identity", - "Privacy", - "Social" + "Collective Intelligence", + "Civil Resistance", + "DePIN", + "Autonomous World", + "robots", + "Autonomous World", + "Civil Resistance", + "Collective Intelligence", + "DePIN" ], "language": "en", "speakers": [ - "vid-kersic" + "tomasz-stanczak" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731647400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE" }, "vector": [ 0, @@ -301035,6 +301268,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -301349,9 +301583,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -301790,6 +302024,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -301800,6 +302036,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -301817,7 +302054,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -301876,6 +302112,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -301885,7 +302127,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -301948,7 +302189,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -301994,6 +302234,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -302064,6 +302312,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -302078,26 +302334,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, @@ -302336,9 +302572,6 @@ 0, 0, 0, - 0, - 0, - 0, 2, 0, 0, @@ -302347,41 +302580,44 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "ethereum-culture-expanding-in-the-infinite-garden", - "sourceId": "ZS338S", - "title": "Ethereum Culture Expanding in the Infinite Garden", - "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.", + "id": "ethereum-citizen-embracing-self-sovereign-digital-identity", + "sourceId": "ATKWT8", + "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity", + "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.", "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Culture", - "Subculture", - "Infinite Garden" + "Attestations", + "data" ], "tags": [ - "Values", - "infinite", - "garden", - "Values" + "Privacy", + "Identity", + "Social", + "data", + "Identity", + "Privacy", + "Social" ], "language": "en", "speakers": [ - "tomo-saito" + "vid-kersic" ], "eventId": "devcon-7", - "slot_start": 1731649200000, - "slot_end": 1731650400000, + "slot_start": 1731646800000, + "slot_end": 1731647400000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog" + "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I" }, "vector": [ 0, @@ -302446,8 +302682,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -302707,6 +302941,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -303173,6 +303408,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -303234,13 +303470,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -303303,6 +303539,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -303434,8 +303671,6 @@ 0, 0, 2, - 2, - 0, 0, 0, 0, @@ -303693,6 +303928,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -303706,50 +303943,44 @@ }, { "session": { - "id": "ethereum-execution-layer-specifications-eels", - "sourceId": "3GCD7S", - "title": "Ethereum Execution Layer Specifications (EELS)", - "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.", - "track": "Core Protocol", + "id": "ethereum-culture-expanding-in-the-infinite-garden", + "sourceId": "ZS338S", + "title": "Ethereum Culture Expanding in the Infinite Garden", + "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.", + "track": "Cypherpunk & Privacy", "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Core Protocol", - "Layer 1" - ], "keywords": [ - "Execution", - "Layer" + "Culture", + "Subculture", + "Infinite Garden" + ], + "tags": [ + "Values", + "infinite", + "garden", + "Values" ], - "duration": 1253, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "WEvCFg0Z1D4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt", - "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c", - "resources_slides": null, "speakers": [ - "guruprasad-kamath" - ] + "tomo-saito" + ], + "eventId": "devcon-7", + "slot_start": 1731649200000, + "slot_end": 1731650400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog" }, "vector": [ 0, 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -303806,6 +304037,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -304066,7 +304298,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -304497,11 +304728,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -304597,6 +304826,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304796,6 +305026,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -305044,16 +305276,16 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -305066,36 +305298,48 @@ }, { "session": { - "id": "ethereum-in-30-minutes", - "sourceId": "GAJPCN", - "title": "Ethereum in 30 minutes", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", + "id": "ethereum-execution-layer-specifications-eels", + "sourceId": "3GCD7S", + "title": "Ethereum Execution Layer Specifications (EELS)", + "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.", + "track": "Core Protocol", "type": "Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "vitalik-buterin" + "tags": [ + "Core Protocol", + "Layer 1" + ], + "keywords": [ + "Execution", + "Layer" ], + "duration": 1253, + "language": "en", + "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802", + "sources_youtubeId": "WEvCFg0Z1D4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt", + "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.", "eventId": "devcon-7", - "slot_start": 1731384000000, - "slot_end": 1731385800000, - "slot_roomId": "main-stage", - "sources_youtubeId": "ei3tDRMjw6k", - "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I" + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c", + "resources_slides": null, + "speakers": [ + "guruprasad-kamath" + ] }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -305284,7 +305528,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -305415,6 +305658,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -305846,9 +306090,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -306394,10 +306640,11 @@ 2, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -306412,34 +306659,29 @@ }, { "session": { - "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires", - "sourceId": "9HFAES", - "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires", - "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.", + "id": "ethereum-in-30-minutes", + "sourceId": "GAJPCN", + "title": "Ethereum in 30 minutes", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Academic", + "type": "Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Education" - ], - "tags": [ - "Design Thinking", - "Ethereum for Good", - "Public good" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "romina-sejas", - "juan-david-reyes" + "vitalik-buterin" ], "eventId": "devcon-7", - "slot_start": 1731559200000, - "slot_end": 1731559800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw" + "slot_start": 1731384000000, + "slot_end": 1731385800000, + "slot_roomId": "main-stage", + "sources_youtubeId": "ei3tDRMjw6k", + "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9", + "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I" }, "vector": [ 0, @@ -306636,6 +306878,33 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -306765,8 +307034,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -307289,11 +307556,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -307306,10 +307568,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -307324,20 +307582,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -307742,6 +307986,7 @@ 0, 0, 0, + 2, 0, 0, 2, @@ -307755,8 +308000,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0 @@ -307764,33 +308007,34 @@ }, { "session": { - "id": "ethereum-needs-native-l2", - "sourceId": "9RNWDX", - "title": "Ethereum needs native L2", - "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires", + "sourceId": "9HFAES", + "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires", + "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "interoperability" + "Education" ], "tags": [ - "Cross-L2", - "Ethereum Roadmap", - "Scalability" + "Design Thinking", + "Ethereum for Good", + "Public good" ], "language": "en", "speakers": [ - "koeppelmann" + "romina-sejas", + "juan-david-reyes" ], "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A" + "slot_start": 1731559200000, + "slot_end": 1731559800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw" }, "vector": [ 0, @@ -307799,7 +308043,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -307972,7 +308215,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -308118,6 +308360,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -308641,6 +308885,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -308657,6 +308902,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -308671,10 +308917,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -308731,7 +308977,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -308768,7 +309013,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -309093,7 +309337,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -309108,6 +309351,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0 @@ -309115,39 +309360,33 @@ }, { "session": { - "id": "ethereum-privacy-ecosystem-overview", - "sourceId": "GDSWLR", - "title": "Ethereum Privacy Ecosystem overview", - "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links", - "track": "Cypherpunk & Privacy", + "id": "ethereum-needs-native-l2", + "sourceId": "9RNWDX", + "title": "Ethereum needs native L2", + "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "hackathons", - "funding", - "" + "interoperability" ], "tags": [ - "Privacy", - "Censorship Resistance", - "Use Cases", - "funding", - "Censorship Resistance", - "Privacy", - "Use Cases" + "Cross-L2", + "Ethereum Roadmap", + "Scalability" ], "language": "en", "speakers": [ - "mykola-siusko" + "koeppelmann" ], "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731398400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q" + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A" }, "vector": [ 0, @@ -309155,9 +309394,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -309329,6 +309568,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -309475,7 +309715,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -309967,7 +310206,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310005,7 +310243,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310031,12 +310268,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -310085,6 +310322,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -310092,6 +310330,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -310201,7 +310440,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310456,10 +310694,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -310472,42 +310712,39 @@ }, { "session": { - "id": "ethereum-real-world-economy", - "sourceId": "JSYMFD", - "title": "Ethereum Real World Economy", - "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?", - "track": "Real World Ethereum", - "type": "Panel", + "id": "ethereum-privacy-ecosystem-overview", + "sourceId": "GDSWLR", + "title": "Ethereum Privacy Ecosystem overview", + "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links", + "track": "Cypherpunk & Privacy", + "type": "Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "stablecoins", - "real-world-use", - "use-cases" + "hackathons", + "funding", + "" ], "tags": [ - "Ethereum Roadmap", + "Privacy", + "Censorship Resistance", "Use Cases", - "e/acc", - "case", - "use", - "e/acc", - "Ethereum Roadmap", + "funding", + "Censorship Resistance", + "Privacy", "Use Cases" ], "language": "en", "speakers": [ - "nalin-b", - "dc-posch", - "liam-horne" + "mykola-siusko" ], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731574800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms" + "slot_start": 1731396600000, + "slot_end": 1731398400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q" }, "vector": [ 0, @@ -310515,7 +310752,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -310655,7 +310891,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -310715,7 +310950,8 @@ 0, 0, 0, - 6, + 0, + 0, 0, 0, 0, @@ -311327,6 +311563,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -311365,6 +311603,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -311395,6 +311634,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -311404,7 +311644,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -311485,7 +311724,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -311814,12 +312052,12 @@ 0, 2, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -311832,31 +312070,42 @@ }, { "session": { - "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter", - "sourceId": "XSCFZR", - "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter", - "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.", + "id": "ethereum-real-world-economy", + "sourceId": "JSYMFD", + "title": "Ethereum Real World Economy", + "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?", "track": "Real World Ethereum", - "type": "Talk", + "type": "Panel", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "stablecoins", + "real-world-use", + "use-cases" + ], "tags": [ - "Autonomous World", - "Gaming", + "Ethereum Roadmap", + "Use Cases", + "e/acc", + "case", + "use", + "e/acc", + "Ethereum Roadmap", "Use Cases" ], "language": "en", "speakers": [ - "dhrumil-shah" + "nalin-b", + "dc-posch", + "liam-horne" ], "eventId": "devcon-7", - "slot_start": 1731494400000, - "slot_end": 1731496200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0" + "slot_start": 1731571200000, + "slot_end": 1731574800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms" }, "vector": [ 0, @@ -311935,8 +312184,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -312006,6 +312253,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -312065,6 +312313,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -312185,6 +312434,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -312707,36 +312957,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -312783,6 +313003,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312820,6 +313041,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312940,6 +313162,34 @@ 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, @@ -313181,43 +313431,31 @@ }, { "session": { - "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now", - "sourceId": "UHAESN", - "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now", - "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?", - "track": "Cypherpunk & Privacy", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Community", + "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter", + "sourceId": "XSCFZR", + "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter", + "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ethos", - "values", - "alignment" - ], + "keywords": [], "tags": [ - "Layer 1", - "Ethereum Roadmap", - "Coordination", - "alignment", - "Coordination", - "Ethereum Roadmap", - "Layer 1" + "Autonomous World", + "Gaming", + "Use Cases" ], "language": "en", "speakers": [ - "peter-szilagyi", - "ahmad-bitar", - "phil-ngo", - "nixo", - "mark-tyneway" + "dhrumil-shah" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731567600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI" + "slot_start": 1731494400000, + "slot_end": 1731496200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0" }, "vector": [ 0, @@ -313225,6 +313463,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -313295,6 +313534,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -313392,7 +313632,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -313481,7 +313720,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -313547,9 +313785,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -313973,7 +314208,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -314042,6 +314276,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -314072,6 +314307,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -314113,7 +314350,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -314195,7 +314431,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -314273,7 +314508,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -314520,7 +314754,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -314528,6 +314761,7 @@ 0, 0, 0, + 2, 0, 2, 0, @@ -314537,54 +314771,61 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "ethersjs-api-hidden-gems", - "sourceId": "EG8ML8", - "title": "Ethers.js - API Hidden Gems", - "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.", - "track": "Developer Experience", - "type": "Talk", + "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now", + "sourceId": "UHAESN", + "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now", + "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?", + "track": "Cypherpunk & Privacy", + "type": "Panel", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Ethers", - "API" + "ethos", + "values", + "alignment" ], "tags": [ - "DevEx", - "Testing", - "UI/UX", - "api", - "DevEx", - "Testing", - "UI/UX" + "Layer 1", + "Ethereum Roadmap", + "Coordination", + "alignment", + "Coordination", + "Ethereum Roadmap", + "Layer 1" ], "language": "en", "speakers": [ - "richard-moore" + "peter-szilagyi", + "ahmad-bitar", + "phil-ngo", + "nixo", + "mark-tyneway" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac" + "slot_start": 1731564000000, + "slot_end": 1731567600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI" }, "vector": [ - 0, - 0, - 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -314751,6 +314992,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -314839,6 +315081,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -314904,9 +315147,11 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -315329,6 +315574,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -315344,7 +315590,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -315373,7 +315618,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -315470,6 +315714,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -315508,6 +315753,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -315556,7 +315802,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -315882,10 +316127,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -315898,38 +316143,44 @@ }, { "session": { - "id": "ethos-dgen1-self-sovereign-os-hardware", - "sourceId": "TALWUM", - "title": "ethOS + dGEN1: Self sovereign OS + Hardware", - "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", + "id": "ethersjs-api-hidden-gems", + "sourceId": "EG8ML8", + "title": "Ethers.js - API Hidden Gems", + "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.", + "track": "Developer Experience", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Ethers", + "API" + ], "tags": [ - "DePIN", - "Mobile", + "DevEx", + "Testing", + "UI/UX", + "api", + "DevEx", + "Testing", "UI/UX" ], "language": "en", "speakers": [ - "markus-haas" + "richard-moore" ], "eventId": "devcon-7", - "slot_start": 1731576900000, - "slot_end": 1731577800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c" + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac" }, "vector": [ - 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -316685,8 +316936,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -316697,6 +316946,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316722,10 +316972,11 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -316908,6 +317159,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316981,6 +317233,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -317229,9 +317482,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -317247,48 +317500,40 @@ }, { "session": { - "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum", - "sourceId": "QLK8UE", - "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum", - "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", + "id": "ethos-dgen1-self-sovereign-os-hardware", + "sourceId": "TALWUM", + "title": "ethOS + dGEN1: Self sovereign OS + Hardware", + "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "MUD", - "EVE Frontier", - "EVE Online" - ], + "keywords": [], "tags": [ - "Gaming", - "Autonomous World", - "eve", - "online", - "Autonomous World", - "Gaming" + "DePIN", + "Mobile", + "UI/UX" ], "language": "en", "speakers": [ - "justin-glibert", - "hilmar-petursson" + "markus-haas" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk" + "slot_start": 1731576900000, + "slot_end": 1731577800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -317468,7 +317713,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -318044,6 +318288,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -318079,6 +318325,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -318130,8 +318378,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -318337,8 +318583,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -318586,6 +318830,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -318604,33 +318850,39 @@ }, { "session": { - "id": "eve-frontier-mud-day-demo", - "sourceId": "RMKJTL", - "title": "EVE Frontier - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", + "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum", + "sourceId": "QLK8UE", + "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum", + "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.", + "track": "Real World Ethereum", + "type": "Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Engineering", "featured": false, - "doNotRecord": true, - "keywords": [], + "doNotRecord": false, + "keywords": [ + "MUD", + "EVE Frontier", + "EVE Online" + ], "tags": [ "Gaming", "Autonomous World", + "eve", + "online", "Autonomous World", "Gaming" ], "language": "en", "speakers": [ - "toniya-sundaram", - "scott-mccabe" + "justin-glibert", + "hilmar-petursson" ], "eventId": "devcon-7", - "slot_start": 1731556500000, - "slot_end": 1731556800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI" + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk" }, "vector": [ 0, @@ -318639,13 +318891,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -318784,8 +319036,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -318821,6 +319071,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -318965,6 +319217,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -319689,8 +319942,8 @@ 0, 0, 0, - 0, - 0, + 2, + 2, 0, 0, 0, @@ -319937,11 +320190,11 @@ 0, 2, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -319955,46 +320208,39 @@ }, { "session": { - "id": "everything-you-need-to-know-about-state-expiry", - "sourceId": "MZXQKJ", - "title": "Everything you need to know about state expiry", - "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "eve-frontier-mud-day-demo", + "sourceId": "RMKJTL", + "title": "EVE Frontier - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, - "doNotRecord": false, - "keywords": [ - "Statelessness", - "State expiry" - ], + "doNotRecord": true, + "keywords": [], "tags": [ - "Core Protocol", - "Protocol Design", - "Verkle trees", - "state", - "expiry", - "Core Protocol", - "Protocol Design", - "Verkle trees" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "han" + "toniya-sundaram", + "scott-mccabe" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA" + "slot_start": 1731556500000, + "slot_end": 1731556800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -320003,6 +320249,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -320141,6 +320388,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -320323,7 +320572,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -320747,7 +320995,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -320774,7 +321021,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -320840,6 +321086,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -321047,9 +321297,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -321290,7 +321537,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -321300,6 +321546,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -321312,44 +321560,39 @@ }, { "session": { - "id": "evm-charts-2024-whats-hot-whats-not", - "sourceId": "R3UPGT", - "title": "EVM Charts 2024: What's hot? What's not?", - "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?", + "id": "everything-you-need-to-know-about-state-expiry", + "sourceId": "MZXQKJ", + "title": "Everything you need to know about state expiry", + "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.", "track": "Core Protocol", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Opcodes", - "Precompiles", - "EVM Metrics", - "Protocol Optimization", - "Statistics", - "evm usage trends" + "Statelessness", + "State expiry" ], "tags": [ "Core Protocol", - "Architecture", - "Gas", - "EVM", - "trend", - "usage", - "Architecture", + "Protocol Design", + "Verkle trees", + "state", + "expiry", "Core Protocol", - "Gas" + "Protocol Design", + "Verkle trees" ], "language": "en", "speakers": [ - "dominic-bruetsch" + "han" ], "eventId": "devcon-7", - "slot_start": 1731471000000, - "slot_end": 1731471600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac" + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA" }, "vector": [ 0, @@ -321685,7 +321928,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -322109,9 +322351,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -322138,6 +322380,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -322152,7 +322395,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322287,6 +322529,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -322297,7 +322541,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322318,7 +322561,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322652,9 +322894,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 2, @@ -322669,40 +322912,57 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "evm-memory-repricing-and-gentest", - "sourceId": "MTWH38", - "title": "EVM Memory Repricing & Gentest", - "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.", - "track": "[CLS] EPF Day", + "id": "evm-charts-2024-whats-hot-whats-not", + "sourceId": "R3UPGT", + "title": "EVM Charts 2024: What's hot? What's not?", + "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?", + "track": "Core Protocol", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, - "doNotRecord": true, - "keywords": [], + "doNotRecord": false, + "keywords": [ + "Opcodes", + "Precompiles", + "EVM Metrics", + "Protocol Optimization", + "Statistics", + "evm usage trends" + ], "tags": [ - "EVM-equivalent" + "Core Protocol", + "Architecture", + "Gas", + "EVM", + "trend", + "usage", + "Architecture", + "Core Protocol", + "Gas" ], "language": "en", "speakers": [ - "raxhvl" + "dominic-bruetsch" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731469500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY" + "slot_start": 1731471000000, + "slot_end": 1731471600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -322714,8 +322974,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -323458,6 +323716,28 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -323479,6 +323759,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -323618,6 +323906,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -323635,6 +323927,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -323725,6 +324019,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -323761,42 +324057,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, @@ -324021,53 +324281,35 @@ }, { "session": { - "id": "evm-object-format-eof-history-and-motivation", - "sourceId": "SEUZGU", - "title": "EVM Object Format (EOF) - History and motivation", - "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.", - "track": "Core Protocol", - "type": "Talk", + "id": "evm-memory-repricing-and-gentest", + "sourceId": "MTWH38", + "title": "EVM Memory Repricing & Gentest", + "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, - "doNotRecord": false, + "doNotRecord": true, + "keywords": [], "tags": [ - "Core Protocol", - "developer", - "experience", - "Core", - "Protocol" - ], - "keywords": [ - "EVM", - "Developer Experience" + "EVM-equivalent" ], - "duration": 1503, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "X2mlptWzphc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro", - "resources_slides": null, "speakers": [ - "danno-ferrin" - ] + "raxhvl" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731469500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -324079,6 +324321,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -324819,7 +325062,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -324975,7 +325217,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -325104,8 +325345,11 @@ 0, 0, 0, - 2, - 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -325362,12 +325606,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -325384,39 +325629,45 @@ }, { "session": { - "id": "evm-object-format-eof-managing-the-bytecode-chaos", - "sourceId": "UU9BTK", - "title": "EVM Object Format (EOF): Managing the Bytecode Chaos", - "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF", + "id": "evm-object-format-eof-history-and-motivation", + "sourceId": "SEUZGU", + "title": "EVM Object Format (EOF) - History and motivation", + "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.", "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "EOF", - "EIP", - "upgrades" - ], "tags": [ - "Ethereum Roadmap", - "Protocol Design", - "Security", - "upgrade", - "Ethereum Roadmap", - "Protocol Design", - "Security" + "Core Protocol", + "developer", + "experience", + "Core", + "Protocol" ], - "language": "en", - "speakers": [ - "alex-murashkin" + "keywords": [ + "EVM", + "Developer Experience" ], + "duration": 1503, + "language": "en", + "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496", + "sources_youtubeId": "X2mlptWzphc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro", + "resources_slides": null, + "speakers": [ + "danno-ferrin" + ] }, "vector": [ 0, @@ -325755,7 +326006,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -326157,7 +326407,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -326179,6 +326428,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -326203,7 +326453,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -326335,6 +326584,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -326394,7 +326644,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -326465,6 +326714,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -326719,6 +326970,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -326741,34 +326993,39 @@ }, { "session": { - "id": "evmmax-fast-modular-arithmetic-in-evm", - "sourceId": "7CWEHH", - "title": "EVMMAX. Fast Modular Arithmetic in EVM", - "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.", + "id": "evm-object-format-eof-managing-the-bytecode-chaos", + "sourceId": "UU9BTK", + "title": "EVM Object Format (EOF): Managing the Bytecode Chaos", + "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF", "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ "EOF", - "EVM" + "EIP", + "upgrades" ], "tags": [ - "Cryptography", - "EVM", - "Cryptography" + "Ethereum Roadmap", + "Protocol Design", + "Security", + "upgrade", + "Ethereum Roadmap", + "Protocol Design", + "Security" ], "language": "en", "speakers": [ - "rodiazet" + "alex-murashkin" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, + "slot_start": 1731552300000, + "slot_end": 1731554100000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk" + "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk" }, "vector": [ 0, @@ -327108,7 +327365,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -327511,6 +327767,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -327522,7 +327779,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -327557,6 +327813,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -327704,6 +327961,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -327716,7 +327974,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -327836,6 +328093,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -328075,9 +328333,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -328093,52 +328351,41 @@ }, { "session": { - "id": "evolution-of-scams", - "sourceId": "WZWPE9", - "title": "Evolution of Scams", - "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.", - "track": "Security", - "type": "Lightning Talk", + "id": "evmmax-fast-modular-arithmetic-in-evm", + "sourceId": "7CWEHH", + "title": "EVMMAX. Fast Modular Arithmetic in EVM", + "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Developer", "featured": false, "doNotRecord": false, - "tags": [ - "metamask", - "Hacks", - "Security" - ], "keywords": [ - "Security", - "Drainers", - "MetaMask" + "EOF", + "EVM" + ], + "tags": [ + "Cryptography", + "EVM", + "Cryptography" ], - "duration": 558, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "SgkEwSDkBnI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt", - "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", - "eventId": "devcon-7", - "slot_start": 1731408600000, - "slot_end": 1731409200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0", - "resources_slides": null, "speakers": [ - "ohm" - ] + "rodiazet" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk" }, "vector": [ - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -328871,7 +329118,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -328887,6 +329133,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -329081,6 +329329,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -329122,7 +329373,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -329198,7 +329448,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -329438,8 +329687,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -329455,41 +329704,46 @@ }, { "session": { - "id": "exploring-auction-mechanisms-in-protocol-design", - "sourceId": "WAKEL9", - "title": "Exploring Auction Mechanisms in Protocol Design", - "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.", - "track": "Cryptoeconomics", + "id": "evolution-of-scams", + "sourceId": "WZWPE9", + "title": "Evolution of Scams", + "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.", + "track": "Security", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Auction" - ], "tags": [ - "Core Protocol", - "Economics", - "MEV", - "auction", - "Core Protocol", - "Economics", - "MEV" + "metamask", + "Hacks", + "Security" ], - "language": "en", - "speakers": [ - "terence" + "keywords": [ + "Security", + "Drainers", + "MetaMask" ], + "duration": 558, + "language": "en", + "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537", + "sources_youtubeId": "SgkEwSDkBnI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt", + "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", "eventId": "devcon-7", - "slot_start": 1731485400000, - "slot_end": 1731486000000, + "slot_start": 1731408600000, + "slot_end": 1731409200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4" + "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0", + "resources_slides": null, + "speakers": [ + "ohm" + ] }, "vector": [ - 0, - 0, 6, 0, 0, @@ -329828,6 +330082,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -330245,7 +330500,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -330261,7 +330515,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -330482,6 +330735,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -330554,8 +330809,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -330792,10 +331047,12 @@ 0, 2, 0, - 2, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -330810,37 +331067,42 @@ }, { "session": { - "id": "exploring-mud-worlds-with-blockscout", - "sourceId": "QTLXWL", - "title": "Exploring MUD worlds with Blockscout", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "exploring-auction-mechanisms-in-protocol-design", + "sourceId": "WAKEL9", + "title": "Exploring Auction Mechanisms in Protocol Design", + "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.", + "track": "Cryptoeconomics", "type": "Lightning Talk", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Block", - "Explorers" + "Auction" ], "tags": [ - "Appchains", - "Interface" + "Core Protocol", + "Economics", + "MEV", + "auction", + "Core Protocol", + "Economics", + "MEV" ], "language": "en", "speakers": [ - "kirill-fedoseev" + "terence" ], "eventId": "devcon-7", - "slot_start": 1731555300000, - "slot_end": 1731555600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro" + "slot_start": 1731485400000, + "slot_end": 1731486000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4" }, "vector": [ 0, 0, + 6, 0, 0, 0, @@ -330851,8 +331113,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -331581,6 +331841,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -331597,6 +331858,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -331612,6 +331874,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -331719,8 +331982,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -332141,6 +332402,7 @@ 0, 0, 0, + 0, 2, 0, 2, @@ -332161,33 +332423,33 @@ }, { "session": { - "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum", - "sourceId": "TVSAZU", - "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.", - "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", + "id": "exploring-mud-worlds-with-blockscout", + "sourceId": "QTLXWL", + "title": "Exploring MUD worlds with Blockscout", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "N/A" + "Block", + "Explorers" ], "tags": [ - "Identity", - "Privacy", - "Zero-Knowledge" + "Appchains", + "Interface" ], "language": "en", "speakers": [ - "remco-bloeman" + "kirill-fedoseev" ], "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs" + "slot_start": 1731555300000, + "slot_end": 1731555600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro" }, "vector": [ 0, @@ -332196,14 +332458,13 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -332940,7 +333201,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -332977,7 +333237,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -333045,7 +333304,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -333075,6 +333333,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -333259,6 +333520,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -333490,12 +333752,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -333512,45 +333775,50 @@ }, { "session": { - "id": "exploring-the-future-of-account-abstraction", - "sourceId": "S7NYUJ", - "title": "Exploring the Future of Account Abstraction", - "description": "Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).", - "track": "Core Protocol", + "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum", + "sourceId": "TVSAZU", + "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.", + "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.", + "track": "Real World Ethereum", "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", - "featured": true, + "audience": "Engineering", + "featured": false, "doNotRecord": false, - "keywords": [ - "AA", - "roadmap" - ], "tags": [ - "Ethereum Roadmap", - "In-protocol Account Abstraction", - "Account Abstraction", - "aa", - "roadmap", - "Account Abstraction", - "Ethereum Roadmap", - "In-protocol Account Abstraction" + "Identity", + "Privacy", + "Zero-Knowledge" ], - "language": "en", - "speakers": [ - "yoav-weiss" + "keywords": [ + "N/A" ], + "duration": 1479, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "q3rpu8aDRA8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731562200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM" + "slot_start": 1731409200000, + "slot_end": 1731411000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs", + "resources_slides": null, + "speakers": [ + "remco-bloeman" + ] }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -333887,10 +334155,12 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -334294,6 +334564,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -334329,6 +334601,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -334336,7 +334609,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -334397,6 +334669,40 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -334504,7 +334810,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -334522,7 +334827,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -334615,43 +334919,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -334851,9 +335118,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -334869,48 +335136,50 @@ }, { "session": { - "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols", - "sourceId": "LGZYYW", - "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols", - "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.", - "track": "Usability", - "type": "Lightning Talk", + "id": "exploring-the-future-of-account-abstraction", + "sourceId": "S7NYUJ", + "title": "Exploring the Future of Account Abstraction", + "description": "Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, + "audience": "Developer", + "featured": true, "doNotRecord": false, "keywords": [ - "TEE" + "AA", + "roadmap" ], "tags": [ - "TEE", - "Decentralization", - "Homomorphic Encryption", - "Intents", - "MPC", - "ZKP" + "Ethereum Roadmap", + "In-protocol Account Abstraction", + "Account Abstraction", + "aa", + "roadmap", + "Account Abstraction", + "Ethereum Roadmap", + "In-protocol Account Abstraction" ], "language": "en", "speakers": [ - "mounir-benchemled" + "yoav-weiss" ], "eventId": "devcon-7", - "slot_start": 1731558000000, - "slot_end": 1731558600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8" + "slot_start": 1731560400000, + "slot_end": 1731562200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -335692,9 +335961,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -335714,7 +335985,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -335728,8 +335998,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -335741,7 +336009,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -335837,6 +336104,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -335863,6 +336131,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -335972,6 +336241,8 @@ 0, 0, 2, + 2, + 0, 0, 0, 0, @@ -336205,9 +336476,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -336223,51 +336494,47 @@ }, { "session": { - "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire", - "sourceId": "AAYWGY", - "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire", - "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.", - "track": "Cryptoeconomics", - "type": "Talk", + "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols", + "sourceId": "LGZYYW", + "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols", + "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.", + "track": "Usability", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Academic", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Batch auctions", - "dutch auctions", - "auctions", - "CoW Swap", - "research" + "TEE" ], "tags": [ - "Mechanism design", - "Intents", - "research", + "TEE", + "Decentralization", + "Homomorphic Encryption", "Intents", - "Mechanism design" + "MPC", + "ZKP" ], "language": "en", "speakers": [ - "andrea-canidio" + "mounir-benchemled" ], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731652200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU" + "slot_start": 1731558000000, + "slot_end": 1731558600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8" }, "vector": [ 0, 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -337003,8 +337270,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -337051,11 +337316,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -337075,6 +337340,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -337088,6 +337354,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -337099,6 +337367,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -337265,7 +337534,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337329,6 +337597,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -337562,6 +337831,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -337571,7 +337841,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337580,47 +337849,41 @@ }, { "session": { - "id": "farcaster-frames-building-embeddable-ethereum-apps", - "sourceId": "NPGET3", - "title": "Farcaster frames: building embeddable Ethereum apps", - "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.", - "track": "Developer Experience", - "type": "Workshop", + "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire", + "sourceId": "AAYWGY", + "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire", + "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", - "featured": true, + "audience": "Academic", + "featured": false, "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "Social", - "farcaster", - "Developer Infrastructure", - "Social" - ], "keywords": [ - "Farcaster" + "Batch auctions", + "dutch auctions", + "auctions", + "CoW Swap", + "research" + ], + "tags": [ + "Mechanism design", + "Intents", + "research", + "Intents", + "Mechanism design" ], - "duration": 5086, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "LnEpR575FRA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400800000, - "slot_end": 1731406200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M", - "resources_slides": null, "speakers": [ - "horsefacts" - ] + "andrea-canidio" + ], + "eventId": "devcon-7", + "slot_start": 1731650400000, + "slot_end": 1731652200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU" }, "vector": [ - 0, 0, 0, 6, @@ -338367,6 +338630,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -338538,7 +338804,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -338628,6 +338893,46 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -338691,46 +338996,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, @@ -338924,7 +339189,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -338934,6 +339198,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -338942,50 +339207,46 @@ }, { "session": { - "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul", - "sourceId": "SSXAMG", - "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul", - "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", + "id": "farcaster-frames-building-embeddable-ethereum-apps", + "sourceId": "NPGET3", + "title": "Farcaster frames: building embeddable Ethereum apps", + "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Intermediate", "audience": "Engineering", - "featured": false, + "featured": true, "doNotRecord": false, "tags": [ - "Values", - "FOSS", - "Decentralization", - "culture", - "Decentralization", - "FOSS", - "Values" + "Developer Infrastructure", + "Social", + "farcaster", + "Developer Infrastructure", + "Social" ], "keywords": [ - "Culture" + "Farcaster" ], - "duration": 1584, + "duration": 5086, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "sNPxhnznfEA", + "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316", + "sources_youtubeId": "LnEpR575FRA", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt", - "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.", + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw", + "slot_start": 1731400800000, + "slot_end": 1731406200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M", "resources_slides": null, "speakers": [ - "eleftherios-diakomichalis" + "horsefacts" ] }, "vector": [ - 0, - 0, 0, 0, 0, @@ -339331,6 +339592,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -339778,6 +340040,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -339824,7 +340087,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -339834,7 +340096,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -339905,6 +340166,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -339957,7 +340220,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -340056,8 +340318,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -340288,6 +340550,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -340306,29 +340570,46 @@ }, { "session": { - "id": "financialization-in-games", - "sourceId": "EF3P9X", - "title": "Financialization in Games", - "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul", + "sourceId": "SSXAMG", + "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul", + "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.", + "track": "Cypherpunk & Privacy", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, + "tags": [ + "Values", + "FOSS", + "Decentralization", + "culture", + "Decentralization", + "FOSS", + "Values" + ], "keywords": [ - "n/a" + "Culture" ], - "tags": [], + "duration": 1584, "language": "en", - "speakers": [ - "y77cao" - ], + "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc", + "sources_youtubeId": "sNPxhnznfEA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt", + "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.", "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731582300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw", + "resources_slides": null, + "speakers": [ + "eleftherios-diakomichalis" + ] }, "vector": [ 0, @@ -340336,6 +340617,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -340343,8 +340625,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -341173,6 +341453,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -341182,6 +341463,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -341306,6 +341588,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -341402,6 +341685,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -341633,8 +341917,6 @@ 0, 2, 0, - 0, - 0, 2, 0, 0, @@ -341653,25 +341935,29 @@ }, { "session": { - "id": "find-yourself-on-the-mat", - "sourceId": "PYKTTA", - "title": "Find Yourself on the Mat", - "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", - "audience": "Hobby", + "id": "financialization-in-games", + "sourceId": "EF3P9X", + "title": "Financialization in Games", + "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "n/a" + ], "tags": [], "language": "en", - "speakers": [], + "speakers": [ + "y77cao" + ], "eventId": "devcon-7", - "slot_start": 1731404700000, - "slot_end": 1731407400000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ" + "slot_start": 1731580800000, + "slot_end": 1731582300000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc" }, "vector": [ 0, @@ -341683,10 +341969,11 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -342021,6 +342308,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -342973,6 +343261,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -342985,8 +343274,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -342996,48 +343283,37 @@ }, { "session": { - "id": "finding-bugs-42-tips-from-4-security-researchers", - "sourceId": "AZNENK", - "title": "Finding Bugs: 42 Tips from 4 Security Researchers", - "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.", - "track": "Security", - "type": "Workshop", + "id": "find-yourself-on-the-mat", + "sourceId": "PYKTTA", + "title": "Find Yourself on the Mat", + "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30", + "track": "Entertainment", + "type": "Mixed Formats", "expertise": "Beginner", - "audience": "Research", + "audience": "Hobby", "featured": false, "doNotRecord": false, - "keywords": [ - "Education", - "Hacks", - "Smart Contract Security" - ], - "tags": [ - "Security", - "Auditing", - "Bug", - "Bounties", - "smart", - "contracts", - "Auditing", - "Bounties", - "Bug", - "Security" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "0xrajeev", - "joran-honig", - "nat-chin", - "tincho" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw" + "slot_start": 1731404700000, + "slot_end": 1731407400000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ" }, "vector": [ - 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, 0, 0, 0, @@ -343288,7 +343564,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -343313,7 +343588,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -343386,8 +343660,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -343775,7 +344047,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -343927,7 +344198,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -344033,9 +344303,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -344049,7 +344316,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -344339,7 +344605,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -344351,6 +344616,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -344359,42 +344627,47 @@ }, { "session": { - "id": "finding-rough-consensus-on-issuance", - "sourceId": "GSKJK8", - "title": "Finding rough consensus on issuance", - "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.", - "track": "Core Protocol", - "type": "Talk", + "id": "finding-bugs-42-tips-from-4-security-researchers", + "sourceId": "AZNENK", + "title": "Finding Bugs: 42 Tips from 4 Security Researchers", + "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.", + "track": "Security", + "type": "Workshop", "expertise": "Beginner", - "audience": "Community", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Issuance", - "Lido", - "Ethereum" + "Education", + "Hacks", + "Smart Contract Security" ], "tags": [ - "ethereum", - "Economics", - "Ethereum Roadmap", - "Politics" + "Security", + "Auditing", + "Bug", + "Bounties", + "smart", + "contracts", + "Auditing", + "Bounties", + "Bug", + "Security" ], "language": "en", "speakers": [ - "sacha" + "0xrajeev", + "joran-honig", + "nat-chin", + "tincho" ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ" + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw" }, "vector": [ - 0, - 0, - 0, - 0, 6, 0, 0, @@ -344646,6 +344919,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -344670,6 +344944,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -344743,6 +345018,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -345131,6 +345407,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -345164,7 +345441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -345283,6 +345559,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -345366,7 +345643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -345390,6 +345666,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -345403,6 +345682,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -345436,7 +345716,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -345464,7 +345743,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -345696,11 +345974,11 @@ 2, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -345713,46 +345991,43 @@ }, { "session": { - "id": "finding-your-place-in-crypto", - "sourceId": "CCVGE8", - "title": "Finding your place in crypto", - "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.", - "track": "Coordination", + "id": "finding-rough-consensus-on-issuance", + "sourceId": "GSKJK8", + "title": "Finding rough consensus on issuance", + "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.", + "track": "Core Protocol", "type": "Talk", "expertise": "Beginner", - "audience": "", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Personal", - "Human", - "Purpose" + "Issuance", + "Lido", + "Ethereum" ], "tags": [ - "Governance", - "Decentralization", - "MEV", - "fairness", - "Coordination", - "Governance", - "Social" + "ethereum", + "Economics", + "Ethereum Roadmap", + "Politics" ], "language": "en", "speakers": [ - "chris", - "davide-rezzoli" + "sacha" ], "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA" + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -345760,8 +346035,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -346102,7 +346375,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -346489,7 +346761,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -346526,6 +346797,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -346583,13 +346858,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -346642,7 +346915,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -346667,7 +346939,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -346685,6 +346956,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -346797,6 +347070,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -347051,6 +347325,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -347058,12 +347333,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0 @@ -347071,44 +347346,45 @@ }, { "session": { - "id": "firefly-build-your-own-hardware-wallet", - "sourceId": "LMZKZS", - "title": "Firefly - Build your own hardware wallet", - "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.", - "track": "Developer Experience", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", + "id": "finding-your-place-in-crypto", + "sourceId": "CCVGE8", + "title": "Finding your place in crypto", + "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "DIY", - "Arduino" + "Personal", + "Human", + "Purpose" ], "tags": [ - "DevEx", - "Hacks", - "Hardware wallets", - "arduino", - "DevEx", - "Hacks", - "Hardware wallets" + "Governance", + "Decentralization", + "MEV", + "fairness", + "Coordination", + "Governance", + "Social" ], "language": "en", "speakers": [ - "richard-moore" + "chris", + "davide-rezzoli" ], "eventId": "devcon-7", - "slot_start": 1731473400000, - "slot_end": 1731474000000, + "slot_start": 1731582600000, + "slot_end": 1731583800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU" + "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -347117,6 +347393,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -347435,7 +347712,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -347458,6 +347734,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -347845,6 +348123,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -347873,7 +348152,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -347939,11 +348217,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -347996,6 +348276,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -348020,6 +348301,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -348094,7 +348376,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -348176,12 +348457,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -348411,15 +348691,13 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0 @@ -348427,43 +348705,44 @@ }, { "session": { - "id": "folding-starks-with-the-mova-folding-scheme", - "sourceId": "J78CHZ", - "title": "Folding STARKs with the Mova folding scheme", - "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "firefly-build-your-own-hardware-wallet", + "sourceId": "LMZKZS", + "title": "Firefly - Build your own hardware wallet", + "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Folding", - "Post-Quantum" + "DIY", + "Arduino" ], "tags": [ - "ZKP", - "Zero-Knowledge", - "STARK", - "post-quantum", - "STARK", - "Zero-Knowledge", - "ZKP" + "DevEx", + "Hacks", + "Hardware wallets", + "arduino", + "DevEx", + "Hacks", + "Hardware wallets" ], "language": "en", "speakers": [ - "albert-garreta" + "richard-moore" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM" + "slot_start": 1731473400000, + "slot_end": 1731474000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -348471,7 +348750,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -348791,6 +349069,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -348815,7 +349094,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -349211,7 +349489,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -349231,6 +349508,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -349274,7 +349552,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -349410,7 +349687,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -349454,6 +349730,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -349539,8 +349816,7 @@ 0, 0, 2, - 0, - 0, + 2, 0, 0, 0, @@ -349766,11 +350042,14 @@ 0, 2, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -349783,34 +350062,38 @@ }, { "session": { - "id": "for-the-kingdom-mud-day-demo", - "sourceId": "FM3LCK", - "title": "For The Kingdom - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "folding-starks-with-the-mova-folding-scheme", + "sourceId": "J78CHZ", + "title": "Folding STARKs with the Mova folding scheme", + "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "fully", - "onchain", - "game" + "Folding", + "Post-Quantum" ], "tags": [ - "Autonomous World", - "Gaming" + "ZKP", + "Zero-Knowledge", + "STARK", + "post-quantum", + "STARK", + "Zero-Knowledge", + "ZKP" ], "language": "en", "speakers": [ - "tuyen-dinh" + "albert-garreta" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731557100000, + "slot_start": 1731638700000, + "slot_end": 1731640500000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4" + "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM" }, "vector": [ 0, @@ -349823,8 +350106,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -350168,6 +350449,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -350565,6 +350847,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -350626,6 +350910,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -350661,8 +350946,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -350765,6 +351048,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -350890,6 +351174,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -351117,12 +351402,11 @@ 0, 2, 0, + 2, 0, 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -351135,42 +351419,40 @@ }, { "session": { - "id": "fork-choice-enforced-inclusion-lists-focil", - "sourceId": "CDTX78", - "title": "Fork-Choice enforced Inclusion Lists (FOCIL)", - "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "for-the-kingdom-mud-day-demo", + "sourceId": "FM3LCK", + "title": "For The Kingdom - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Censorship Resistance", - "Inclusion Lists", - "Mechanism Design" + "fully", + "onchain", + "game" ], "tags": [ - "Design", - "mechanism" + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "thomas-thiery" + "tuyen-dinh" ], "eventId": "devcon-7", - "slot_start": 1731570000000, - "slot_end": 1731571800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8" + "slot_start": 1731556800000, + "slot_end": 1731557100000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -351179,6 +351461,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -352015,6 +352298,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -352046,7 +352331,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -352243,7 +352527,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -352465,7 +352748,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -352476,6 +352758,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -352487,49 +352772,42 @@ }, { "session": { - "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions", - "sourceId": "KQCGWV", - "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions", - "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.", - "track": "Security", - "type": "Panel", + "id": "fork-choice-enforced-inclusion-lists-focil", + "sourceId": "CDTX78", + "title": "Fork-Choice enforced Inclusion Lists (FOCIL)", + "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "model checking", - "theorem proving" + "Censorship Resistance", + "Inclusion Lists", + "Mechanism Design" ], "tags": [ - "Security", - "Formal Verification", - "Testing", - "proving", - "theorem", - "Formal Verification", - "Security", - "Testing" + "Design", + "mechanism" ], "language": "en", "speakers": [ - "david-pearce", - "igor-konnov", - "julian-sutherland", - "zoe-p" + "thomas-thiery" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731469500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8" + "slot_start": 1731570000000, + "slot_end": 1731571800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8" }, "vector": [ - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -352576,7 +352854,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -352707,7 +352984,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -352882,7 +353158,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -353263,7 +353538,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -353378,7 +353652,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -353411,6 +353684,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -353460,7 +353739,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -353505,7 +353783,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -353825,12 +354102,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -353847,46 +354125,50 @@ }, { "session": { - "id": "fossify-yourself-for-privacy-and-security", - "sourceId": "TW7QGF", - "title": "FOSSify yourself for privacy and security", - "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Beginner", + "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions", + "sourceId": "KQCGWV", + "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions", + "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.", + "track": "Security", + "type": "Panel", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "free software", - "degoogle", - "self hosting" + "model checking", + "theorem proving" ], "tags": [ - "Privacy", "Security", - "self", - "hosting", - "Privacy", - "Security" + "Formal Verification", + "Testing", + "proving", + "theorem", + "Formal Verification", + "Security", + "Testing" ], "language": "en", "speakers": [ - "mario-havel" + "david-pearce", + "igor-konnov", + "julian-sutherland", + "zoe-p" ], "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731558600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ" + "slot_start": 1731465900000, + "slot_end": 1731469500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8" }, "vector": [ + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -353932,6 +354214,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -354061,6 +354345,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -354188,7 +354473,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -354236,6 +354520,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -354616,10 +354902,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -354731,12 +355017,14 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -354813,6 +355101,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -354841,6 +355145,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -354931,6 +355243,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -354961,43 +355281,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -355181,9 +355464,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 2, 0, @@ -355203,48 +355486,38 @@ }, { "session": { - "id": "fraud-proofs-war", - "sourceId": "UTTXWB", - "title": "Fraud proofs war", - "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "fossify-yourself-for-privacy-and-security", + "sourceId": "TW7QGF", + "title": "FOSSify yourself for privacy and security", + "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!", + "track": "Cypherpunk & Privacy", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, - "doNotRecord": false, - "tags": [ - "Optimistic rollups", - "Challenge period", - "Mechanism design", - "fraud", - "proof", - "Challenge period", - "Mechanism design", - "Optimistic rollups" - ], + "doNotRecord": true, "keywords": [ - "Fraud", - "proofs" + "free software", + "degoogle", + "self hosting" + ], + "tags": [ + "Privacy", + "Security", + "self", + "hosting", + "Privacy", + "Security" ], - "duration": 2519, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "tyouXHiQUmY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt", - "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs", - "resources_slides": null, "speakers": [ - "luca-donno" - ] + "mario-havel" + ], + "eventId": "devcon-7", + "slot_start": 1731553200000, + "slot_end": 1731558600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ" }, "vector": [ 0, @@ -355252,9 +355525,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -355554,6 +355827,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -355606,7 +355880,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -355986,13 +356259,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -356053,7 +356326,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -356104,6 +356376,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -356209,7 +356482,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -356550,6 +356822,7 @@ 0, 0, 0, + 0, 2, 0, 2, @@ -356564,44 +356837,54 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools", - "sourceId": "7TRTQW", - "title": "From Auctions to ZK: An Educational Tour of MPC Tools", - "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.", - "track": "Cypherpunk & Privacy", + "id": "fraud-proofs-war", + "sourceId": "UTTXWB", + "title": "Fraud proofs war", + "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.", + "track": "Layer 2", "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Confidential", - "computing" - ], "tags": [ - "Zero-Knowledge", - "MPC", - "Homomorphic Encryption", - "confidentiality", - "computation", - "Homomorphic Encryption", - "MPC", - "Zero-Knowledge" + "Optimistic rollups", + "Challenge period", + "Mechanism design", + "fraud", + "proof", + "Challenge period", + "Mechanism design", + "Optimistic rollups" ], - "language": "en", - "speakers": [ - "aisling-connolly" + "keywords": [ + "Fraud", + "proofs" ], + "duration": 2519, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "tyouXHiQUmY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt", + "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.", "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731493200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8" + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs", + "resources_slides": null, + "speakers": [ + "luca-donno" + ] }, "vector": [ 0, @@ -356609,10 +356892,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -356736,7 +357018,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -356965,6 +357246,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -357351,10 +357633,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -357412,6 +357694,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -357431,8 +357714,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -357571,6 +357852,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -357904,13 +358186,12 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, 0, 0, + 2, 0, 2, 0, @@ -357921,43 +358202,47 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers", - "sourceId": "LT8BTE", - "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers", - "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.", - "track": "Applied Cryptography", + "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools", + "sourceId": "7TRTQW", + "title": "From Auctions to ZK: An Educational Tour of MPC Tools", + "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.", + "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Performance", - "Optimization" + "Confidential", + "computing" ], "tags": [ - "Layer 2s", - "ZK-EVMs", - "Open Source Software", - "optimization", - "Layer 2s", - "Open Source Software", - "ZK-EVMs" + "Zero-Knowledge", + "MPC", + "Homomorphic Encryption", + "confidentiality", + "computation", + "Homomorphic Encryption", + "MPC", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "leo-jeong" + "aisling-connolly" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI" + "slot_start": 1731491400000, + "slot_end": 1731493200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8" }, "vector": [ 0, @@ -357965,12 +358250,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -358092,6 +358377,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -358320,7 +358606,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -358711,6 +358996,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -358764,7 +359052,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -358786,6 +359073,22 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -358796,25 +359099,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, @@ -359260,15 +359544,17 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -359282,50 +359568,38 @@ }, { "session": { - "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution", - "sourceId": "ZBC9ZM", - "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution", - "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.", - "track": "Real World Ethereum", + "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers", + "sourceId": "LT8BTE", + "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers", + "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Beginner", - "audience": "Business", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "Sustainability", - "Ethereum for Good", - "Public good", - "real-world", - "deployment", - "Ethereum for Good", - "Public good", - "Sustainability" - ], "keywords": [ - "Real-World", - "Deployment" + "Performance", + "Optimization" + ], + "tags": [ + "Layer 2s", + "ZK-EVMs", + "Open Source Software", + "optimization", + "Layer 2s", + "Open Source Software", + "ZK-EVMs" ], - "duration": 974, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "0dSz0CN6bI8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt", - "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which", - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731410400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc", - "resources_slides": null, "speakers": [ - "david-casey", - "arun-maharajan", - "mansi" - ] + "leo-jeong" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI" }, "vector": [ 0, @@ -359334,11 +359608,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -359409,9 +359684,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -360134,6 +360407,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -360165,6 +360439,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -360175,7 +360451,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -360192,7 +360467,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -360249,7 +360523,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -360645,40 +360918,57 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "from-mpc-wallets-to-smart-contract-accounts", - "sourceId": "XMTH8N", - "title": "From MPC Wallets to Smart Contract Accounts", - "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", + "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution", + "sourceId": "ZBC9ZM", + "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution", + "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Business", "featured": false, "doNotRecord": false, - "keywords": [ - "EIP-7702" - ], "tags": [ - "MPC", - "Account Abstraction", - "eip-7702", - "Account Abstraction", - "MPC" + "Sustainability", + "Ethereum for Good", + "Public good", + "real-world", + "deployment", + "Ethereum for Good", + "Public good", + "Sustainability" ], - "language": "en", - "speakers": [ - "phuc-thai" + "keywords": [ + "Real-World", + "Deployment" ], + "duration": 974, + "language": "en", + "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384", + "sources_youtubeId": "0dSz0CN6bI8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt", + "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which", "eventId": "devcon-7", - "slot_start": 1731559200000, - "slot_end": 1731559800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ" + "slot_start": 1731409200000, + "slot_end": 1731410400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc", + "resources_slides": null, + "speakers": [ + "david-casey", + "arun-maharajan", + "mansi" + ] }, "vector": [ 0, @@ -360687,8 +360977,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -360764,8 +361052,9 @@ 0, 0, 0, + 6, 0, - 0, + 6, 0, 0, 0, @@ -361470,8 +361759,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -361508,7 +361795,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -361533,6 +361819,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -361549,6 +361836,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -361605,6 +361893,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -361772,6 +362061,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -361981,10 +362271,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -361998,43 +362288,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum", - "sourceId": "CGTBC7", - "title": "From Nanoseconds to Decades: The Timescales of Ethereum", - "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.", - "track": "Core Protocol", + "id": "from-mpc-wallets-to-smart-contract-accounts", + "sourceId": "XMTH8N", + "title": "From MPC Wallets to Smart Contract Accounts", + "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.", + "track": "Usability", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Fun", - "Data" + "EIP-7702" ], "tags": [ - "Core Protocol", - "data", - "fun", - "Core", - "Protocol" + "MPC", + "Account Abstraction", + "eip-7702", + "Account Abstraction", + "MPC" ], "language": "en", "speakers": [ - "jannik-luhn" + "phuc-thai" ], "eventId": "devcon-7", - "slot_start": 1731469200000, - "slot_end": 1731469800000, + "slot_start": 1731559200000, + "slot_end": 1731559800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk" + "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ" }, "vector": [ + 0, + 0, + 0, + 0, 0, 0, 0, @@ -362393,12 +362687,41 @@ 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, - 6, 0, 0, 0, @@ -362830,6 +363153,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -363077,13 +363403,10 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -363093,6 +363416,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -363126,41 +363457,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, @@ -363330,6 +363626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -363344,12 +363641,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0 @@ -363357,46 +363648,42 @@ }, { "session": { - "id": "from-packets-to-privacy-understanding-and-evolving-network-security", - "sourceId": "XYRFXT", - "title": "From Packets to Privacy: Understanding and Evolving Network Security", - "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.", - "track": "Cypherpunk & Privacy", + "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum", + "sourceId": "CGTBC7", + "title": "From Nanoseconds to Decades: The Timescales of Ethereum", + "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.", + "track": "Core Protocol", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Mixnet", - "VPN" + "Fun", + "Data" ], "tags": [ - "Privacy", - "Anonymity", - "Censorship Resistance", - "vpn", - "Anonymity", - "Censorship Resistance", - "Privacy" + "Core Protocol", + "data", + "fun", + "Core", + "Protocol" ], "language": "en", "speakers": [ - "max-hampshire", - "med-amor" + "jannik-luhn" ], "eventId": "devcon-7", - "slot_start": 1731496200000, - "slot_end": 1731496800000, + "slot_start": 1731469200000, + "slot_end": 1731469800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM" + "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -363757,7 +364044,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -364152,11 +364438,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -364247,7 +364533,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -364278,7 +364563,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -364440,10 +364724,14 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -364694,14 +364982,15 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -364714,48 +365003,47 @@ }, { "session": { - "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond", - "sourceId": "EVSLDH", - "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond", - "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "from-packets-to-privacy-understanding-and-evolving-network-security", + "sourceId": "XYRFXT", + "title": "From Packets to Privacy: Understanding and Evolving Network Security", + "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "PeerDAS", - "FullDAS" + "Mixnet", + "VPN" ], "tags": [ - "Danksharding", - "DAS", - "Scalability", - "fulldas", - "Danksharding", - "DAS", - "Scalability" + "Privacy", + "Anonymity", + "Censorship Resistance", + "vpn", + "Anonymity", + "Censorship Resistance", + "Privacy" ], "language": "en", "speakers": [ - "csaba-kiraly" + "max-hampshire", + "med-amor" ], "eventId": "devcon-7", - "slot_start": 1731575400000, - "slot_end": 1731577200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ" + "slot_start": 1731496200000, + "slot_end": 1731496800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM" }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, 0, + 6, 0, 0, 0, @@ -365115,6 +365403,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -365514,6 +365803,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -365551,7 +365841,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -365605,6 +365894,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -365626,7 +365916,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -365636,6 +365925,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -365842,7 +366132,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -366051,7 +366340,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -366059,6 +366347,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -366070,43 +366361,45 @@ }, { "session": { - "id": "from-web2-security-with-love", - "sourceId": "VYEKSS", - "title": "From Web2 Security With Love", - "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.", - "track": "Security", + "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond", + "sourceId": "EVSLDH", + "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond", + "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Intelligence" + "PeerDAS", + "FullDAS" ], "tags": [ - "Security", - "Hacks", - "intelligence", - "Hacks", - "Security" + "Danksharding", + "DAS", + "Scalability", + "fulldas", + "Danksharding", + "DAS", + "Scalability" ], "language": "en", "speakers": [ - "joe-dobson" + "csaba-kiraly" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI" + "slot_start": 1731575400000, + "slot_end": 1731577200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ" }, "vector": [ - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -366839,7 +367132,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -366907,6 +367199,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -366979,6 +367274,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -367090,10 +367386,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -367195,6 +367489,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -367417,49 +367713,49 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "future-of-onchain-credit-scoring-for-farmers", - "sourceId": "BBEDYL", - "title": "Future of Onchain Credit Scoring for Farmers", - "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "from-web2-security-with-love", + "sourceId": "VYEKSS", + "title": "From Web2 Security With Love", + "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.", + "track": "Security", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Agriculture" + "Intelligence" ], "tags": [ - "Identity", - "agriculture", - "Identity" + "Security", + "Hacks", + "intelligence", + "Hacks", + "Security" ], "language": "en", "speakers": [ - "eddie-kago" + "joe-dobson" ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731580800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -368192,6 +368488,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -368239,7 +368540,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -368440,6 +368740,14 @@ 0, 0, 0, + 2, + 0, + 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -368547,14 +368855,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -368754,8 +369054,6 @@ 0, 2, 0, - 0, - 0, 2, 0, 0, @@ -368774,50 +369072,42 @@ }, { "session": { - "id": "fuzzing-zero-knowledge-infrastructure", - "sourceId": "QYWS83", - "title": "Fuzzing Zero-Knowledge Infrastructure", - "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.", - "track": "Security", - "type": "Talk", + "id": "future-of-onchain-credit-scoring-for-farmers", + "sourceId": "BBEDYL", + "title": "Future of Onchain Credit Scoring for Farmers", + "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.", + "track": "Real World Ethereum", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Metamorphic", - "Testing" + "Agriculture" ], "tags": [ - "ZKP", - "Zero-Knowledge", - "Security", - "Fuzzing", - "Testing", - "metamorphic", - "Fuzzing", - "Security", - "Zero-Knowledge" + "Identity", + "agriculture", + "Identity" ], "language": "en", "speakers": [ - "valentin-wustholz" + "eddie-kago" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U" + "slot_start": 1731580200000, + "slot_end": 1731580800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78" }, "vector": [ - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -369548,8 +369838,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -369560,7 +369848,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -369602,6 +369889,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -369623,7 +369916,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -369790,7 +370082,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -370110,8 +370401,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -370127,53 +370418,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "gas-limit-and-block-execution", - "sourceId": "LPLSDD", - "title": "Gas Limit and Block Execution", - "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.", - "track": "Core Protocol", + "id": "fuzzing-zero-knowledge-infrastructure", + "sourceId": "QYWS83", + "title": "Fuzzing Zero-Knowledge Infrastructure", + "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.", + "track": "Security", "type": "Talk", "expertise": "Intermediate", - "audience": "Stakers/Validators", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "gas limit", - "block execution", - "Execution Layer" + "Metamorphic", + "Testing" ], "tags": [ - "Core Protocol", - "Layer 1", - "Protocol Design", - "execution", - "layer", - "Core Protocol", - "Layer 1", - "Protocol Design" + "ZKP", + "Zero-Knowledge", + "Security", + "Fuzzing", + "Testing", + "metamorphic", + "Fuzzing", + "Security", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "marekm25" + "valentin-wustholz" ], "eventId": "devcon-7", - "slot_start": 1731566400000, - "slot_end": 1731568200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U" }, "vector": [ + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -370908,6 +371199,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -370918,14 +371211,13 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -370952,7 +371244,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -370983,6 +371274,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -371101,7 +371393,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -371151,6 +371442,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -371468,17 +371760,18 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -371490,48 +371783,50 @@ }, { "session": { - "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups", - "sourceId": "KXFHXJ", - "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups", - "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Research", + "id": "gas-limit-and-block-execution", + "sourceId": "LPLSDD", + "title": "Gas Limit and Block Execution", + "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Metering" + "gas limit", + "block execution", + "Execution Layer" ], "tags": [ - "Gas", - "Appchains", - "Mechanism design", - "metering", - "Appchains", - "Gas", - "Mechanism design" + "Core Protocol", + "Layer 1", + "Protocol Design", + "execution", + "layer", + "Core Protocol", + "Layer 1", + "Protocol Design" ], "language": "en", "speakers": [ - "felipe-argento" + "marekm25" ], "eventId": "devcon-7", - "slot_start": 1731583200000, - "slot_end": 1731583800000, + "slot_start": 1731566400000, + "slot_end": 1731568200000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU" + "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -372268,7 +372563,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -372279,9 +372573,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -372308,6 +372604,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -372458,6 +372755,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -372489,7 +372787,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -372590,7 +372887,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -372824,16 +373120,17 @@ 0, 0, 0, + 2, + 0, 0, 0, - 2, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -372845,40 +373142,37 @@ }, { "session": { - "id": "giga-staking-for-school-connectivity", - "sourceId": "ZU3AEJ", - "title": "Giga: Staking for school connectivity", - "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.", - "track": "Real World Ethereum", + "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups", + "sourceId": "KXFHXJ", + "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups", + "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.", + "track": "Layer 2", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "connectivity", - "schools", - "social impact" + "Metering" ], "tags": [ - "Staking", - "Sustainability", - "Ethereum for Good", - "Social", - "impact", - "Ethereum for Good", - "Staking", - "Sustainability" + "Gas", + "Appchains", + "Mechanism design", + "metering", + "Appchains", + "Gas", + "Mechanism design" ], "language": "en", "speakers": [ - "gerben-kijne" + "felipe-argento" ], "eventId": "devcon-7", - "slot_start": 1731577200000, - "slot_end": 1731577800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I" + "slot_start": 1731583200000, + "slot_end": 1731583800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU" }, "vector": [ 0, @@ -372887,9 +373181,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -373628,6 +373921,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -373745,25 +374039,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -373799,7 +374074,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -373870,6 +374144,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -373884,7 +374159,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -374000,6 +374274,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -374180,16 +374470,17 @@ 0, 0, 0, - 0, - 0, - 0, - 2, 0, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -374198,40 +374489,49 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "giga-undepin-to-connect-every-school-in-the-world", - "sourceId": "JXH3T3", - "title": "Giga: (UN)DePIN to connect every school in the world", - "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global", + "id": "giga-staking-for-school-connectivity", + "sourceId": "ZU3AEJ", + "title": "Giga: Staking for school connectivity", + "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.", "track": "Real World Ethereum", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Connectivity", - "real world digital assets", - "" + "connectivity", + "schools", + "social impact" ], "tags": [ - "DePIN", + "Staking", + "Sustainability", "Ethereum for Good", - "Politics" + "Social", + "impact", + "Ethereum for Good", + "Staking", + "Sustainability" ], "language": "en", "speakers": [ - "christopher-fabian" + "gerben-kijne" ], "eventId": "devcon-7", - "slot_start": 1731576000000, - "slot_end": 1731577200000, + "slot_start": 1731577200000, + "slot_end": 1731577800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY" + "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I" }, "vector": [ 0, @@ -374606,7 +374906,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -374994,7 +375293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -375098,12 +375396,13 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -375154,6 +375453,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -375239,6 +375539,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -375307,7 +375608,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -375323,6 +375623,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -375556,37 +375857,44 @@ }, { "session": { - "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing", - "sourceId": "PZACPB", - "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "giga-undepin-to-connect-every-school-in-the-world", + "sourceId": "JXH3T3", + "title": "Giga: (UN)DePIN to connect every school in the world", + "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Connectivity", + "real world digital assets", + "" + ], + "tags": [ + "DePIN", + "Ethereum for Good", + "Politics" + ], "language": "en", "speakers": [ - "tom-cirrito-phd" + "christopher-fabian" ], "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731570300000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8" + "slot_start": 1731576000000, + "slot_end": 1731577200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY" }, "vector": [ - 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -376341,6 +376649,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -376444,6 +376753,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -376652,6 +376962,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -376883,12 +377194,11 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -376901,49 +377211,31 @@ }, { "session": { - "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance", - "sourceId": "ZKNSAL", - "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance", - "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.", - "track": "Coordination", + "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing", + "sourceId": "PZACPB", + "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Product", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Vote Escrow", - "Funding Allocation", - "Voter Analytics" - ], - "tags": [ - "Permissionless", - "Coordination", - "Governance", - "Decentralization", - "Game Theory", - "Tokenomics", - "voting", - "analytics", - "Coordination", - "Decentralization", - "Game Theory", - "Governance", - "Permissionless", - "Tokenomics" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "tanisha-katara" + "tom-cirrito-phd" ], "eventId": "devcon-7", - "slot_start": 1731489000000, - "slot_end": 1731489600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE" + "slot_start": 1731569400000, + "slot_end": 1731570300000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8" }, "vector": [ 0, + 6, 0, 0, 0, @@ -376954,8 +377246,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -377689,7 +377979,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -377725,7 +378014,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -377754,7 +378042,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -377777,13 +378064,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -377836,7 +378121,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -377873,7 +378157,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -378042,7 +378325,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -378246,11 +378528,17 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -378260,40 +378548,55 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "grandine-on-windows", - "sourceId": "SUTU99", - "title": "Grandine on Windows", - "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.", - "track": "[CLS] EPF Day", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance", + "sourceId": "ZKNSAL", + "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance", + "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Rust", - "Client", - "Engineering" + "Vote Escrow", + "Funding Allocation", + "Voter Analytics" ], "tags": [ - "Best Practices", - "Core Protocol", - "Languages" + "Permissionless", + "Coordination", + "Governance", + "Decentralization", + "Game Theory", + "Tokenomics", + "voting", + "analytics", + "Coordination", + "Decentralization", + "Game Theory", + "Governance", + "Permissionless", + "Tokenomics" ], "language": "en", "speakers": [ - "jin-mingjian" + "tanisha-katara" ], "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731482100000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0" + "slot_start": 1731489000000, + "slot_end": 1731489600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE" }, "vector": [ 0, @@ -378307,12 +378610,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -379044,6 +379346,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -379053,7 +379356,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379065,7 +379367,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379081,6 +379382,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -379109,6 +379411,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -379137,6 +379440,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -379189,6 +379493,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -379225,6 +379530,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -379393,6 +379699,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -379587,24 +379903,12 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -379618,38 +379922,35 @@ }, { "session": { - "id": "grapheneos-a-brief-introduction-to-private-and-secure-android", - "sourceId": "QK3ZTL", - "title": "GrapheneOS: a brief introduction to private and secure Android", - "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.", - "track": "Cypherpunk & Privacy", + "id": "grandine-on-windows", + "sourceId": "SUTU99", + "title": "Grandine on Windows", + "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.", + "track": "[CLS] EPF Day", "type": "Talk", "expertise": "Beginner", "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Android" + "Rust", + "Client", + "Engineering" ], "tags": [ - "Privacy", - "Security", - "Mobile", - "android", - "Mobile", - "Privacy", - "Security" + "Best Practices", + "Core Protocol", + "Languages" ], "language": "en", "speakers": [ - "hulk", - "maade" + "jin-mingjian" ], "eventId": "devcon-7", - "slot_start": 1731486000000, - "slot_end": 1731487800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw" + "slot_start": 1731481200000, + "slot_end": 1731482100000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0" }, "vector": [ 0, @@ -379657,8 +379958,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -379669,6 +379968,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -380030,7 +380330,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -380390,7 +380689,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -380425,6 +380723,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380490,6 +380789,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -380507,7 +380811,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -380752,7 +381055,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -380974,33 +381276,38 @@ }, { "session": { - "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items", - "sourceId": "AZCYRS", - "title": "Growing The Biomes GDP Using Digital Matter & Smart Items", - "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "grapheneos-a-brief-introduction-to-private-and-secure-android", + "sourceId": "QK3ZTL", + "title": "GrapheneOS: a brief introduction to private and secure Android", + "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.", + "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Beginner", "audience": "Engineering", "featured": false, - "doNotRecord": false, - "keywords": [], + "doNotRecord": true, + "keywords": [ + "Android" + ], "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" + "Privacy", + "Security", + "Mobile", + "android", + "Mobile", + "Privacy", + "Security" ], "language": "en", "speakers": [ - "dhrumil-shah", - "dhvani-patel" + "hulk", + "maade" ], "eventId": "devcon-7", - "slot_start": 1731579300000, - "slot_end": 1731580800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4" + "slot_start": 1731486000000, + "slot_end": 1731487800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw" }, "vector": [ 0, @@ -381008,6 +381315,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -381015,8 +381323,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -381079,8 +381385,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -381383,6 +381687,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -381743,6 +382049,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -381765,6 +382072,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -381851,8 +382159,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -381860,6 +382166,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -382104,6 +382411,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -382325,11 +382633,11 @@ }, { "session": { - "id": "hacking-thai-beats-cities-and-dances", - "sourceId": "NM8B9E", - "title": "Hacking Thai Beats, Cities & Dances", - "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.", - "track": "Real World Ethereum", + "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items", + "sourceId": "AZCYRS", + "title": "Growing The Biomes GDP Using Digital Matter & Smart Items", + "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Talk", "expertise": "Beginner", "audience": "Engineering", @@ -382337,19 +382645,21 @@ "doNotRecord": false, "keywords": [], "tags": [ - "Art", - "FOSS", - "Live Coding" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "phoomparin-mano" + "dhrumil-shah", + "dhvani-patel" ], "eventId": "devcon-7", - "slot_start": 1731552900000, - "slot_end": 1731554100000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0" + "slot_start": 1731567000000, + "slot_end": 1731568500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4" }, "vector": [ 0, @@ -382358,13 +382668,15 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -382426,6 +382738,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -382731,7 +383045,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -383199,6 +383512,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -383206,8 +383520,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -383424,7 +383736,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -383674,37 +383985,31 @@ }, { "session": { - "id": "hallucinated-servers-another-prog-crypto-chip", - "sourceId": "DYJ88A", - "title": "hallucinated servers another prog crypto chip", - "description": "hallucinated servers another prog crypto chip\r\n\r\nNot sure about the rest ;)", - "track": "Applied Cryptography", + "id": "hacking-thai-beats-cities-and-dances", + "sourceId": "NM8B9E", + "title": "Hacking Thai Beats, Cities & Dances", + "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.", + "track": "Real World Ethereum", "type": "Talk", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Cyprography", - "fhe", - "mpc" - ], + "keywords": [], "tags": [ - "Cryptography", - "MPC", - "fhe", - "Cryptography", - "MPC" + "Art", + "FOSS", + "Live Coding" ], "language": "en", "speakers": [ - "brian-lawrence" + "phoomparin-mano" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo" + "slot_start": 1731552900000, + "slot_end": 1731554100000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0" }, "vector": [ 0, @@ -383713,12 +384018,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -384458,7 +384762,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -384534,7 +384837,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -384557,12 +384859,15 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -384780,6 +385085,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -384808,7 +385115,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -385029,42 +385335,39 @@ }, { "session": { - "id": "hardening-mobile-operating-systems-for-enhanced-privacy", - "sourceId": "DRKWGV", - "title": "Hardening Mobile Operating Systems for Enhanced Privacy", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", + "id": "hallucinated-servers-another-prog-crypto-chip", + "sourceId": "DYJ88A", + "title": "hallucinated servers another prog crypto chip", + "description": "hallucinated servers another prog crypto chip\r\n\r\nNot sure about the rest ;)", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Cyprography", + "fhe", + "mpc" + ], + "tags": [ + "Cryptography", + "MPC", + "fhe", + "Cryptography", + "MPC" + ], "language": "en", - "speakers": [], + "speakers": [ + "brian-lawrence" + ], "eventId": "devcon-7", - "slot_start": 1731576000000, - "slot_end": 1731576900000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1d2aapQyYzhgjOalAv-TJnnfo0oZ8Q-k-T4Lsok_kqbY" + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -385075,6 +385378,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -385444,6 +385748,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -385815,6 +386120,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -385890,6 +386196,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -386163,6 +386470,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -386351,9 +386666,13 @@ 0, 0, 0, - 2, 0, 0, + 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -386372,40 +386691,29 @@ }, { "session": { - "id": "hardening-the-commons", - "sourceId": "BMTVJK", - "title": "Hardening the Commons", - "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.", - "track": "Coordination", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", + "id": "hardening-mobile-operating-systems-for-enhanced-privacy", + "sourceId": "DRKWGV", + "title": "Hardening Mobile Operating Systems for Enhanced Privacy", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Impact", - "Commons", - "Adoption" - ], - "tags": [ - "adoption", - "Censorship Resistance", - "Coordination", - "Solarpunk" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "tim-beiko", - "venkatesh-rao" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731497400000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs" + "slot_start": 1731576000000, + "slot_end": 1731576900000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1d2aapQyYzhgjOalAv-TJnnfo0oZ8Q-k-T4Lsok_kqbY" }, "vector": [ 0, + 6, 0, 0, 0, @@ -386416,7 +386724,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -386595,7 +386902,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -386786,7 +387092,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -387268,7 +387573,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -387291,17 +387595,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -387707,7 +388008,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -387717,6 +388017,14 @@ 2, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -387727,44 +388035,42 @@ }, { "session": { - "id": "hardhat-3-preview-overhauled-and-rust-powered", - "sourceId": "QZYQYE", - "title": "Hardhat 3 Preview: Overhauled & Rust-Powered", - "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", + "id": "hardening-the-commons", + "sourceId": "BMTVJK", + "title": "Hardening the Commons", + "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.", + "track": "Coordination", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Hardhat", - "Solidity" + "Impact", + "Commons", + "Adoption" ], "tags": [ - "Developer Infrastructure", - "Tooling", - "DevEx", - "solidity", - "Developer Infrastructure", - "DevEx", - "Tooling" + "adoption", + "Censorship Resistance", + "Coordination", + "Solarpunk" ], "language": "en", "speakers": [ - "patricio-palladino" + "tim-beiko", + "venkatesh-rao" ], "eventId": "devcon-7", - "slot_start": 1731495600000, + "slot_start": 1731486600000, "slot_end": 1731497400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw" + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -387773,6 +388079,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -387951,6 +388258,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -388141,9 +388449,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -388520,7 +388828,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -388529,7 +388836,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -388553,7 +388859,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -388627,6 +388932,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -388649,14 +388955,17 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -388863,7 +389172,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -389061,16 +389369,16 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -389083,41 +389391,44 @@ }, { "session": { - "id": "hardware-security-from-sand-to-stone", - "sourceId": "UZDFEK", - "title": "Hardware Security: From Sand to Stone", - "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", + "id": "hardhat-3-preview-overhauled-and-rust-powered", + "sourceId": "QZYQYE", + "title": "Hardhat 3 Preview: Overhauled & Rust-Powered", + "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.", + "track": "Developer Experience", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "TEE", - "Hardware Trojans" + "Hardhat", + "Solidity" ], "tags": [ - "Decentralization", - "Hardware wallets", - "Security" + "Developer Infrastructure", + "Tooling", + "DevEx", + "solidity", + "Developer Infrastructure", + "DevEx", + "Tooling" ], "language": "en", "speakers": [ - "quintus-kilbourn" + "patricio-palladino" ], "eventId": "devcon-7", - "slot_start": 1731575400000, - "slot_end": 1731576000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4" + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw" }, "vector": [ - 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -389851,7 +390162,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -389875,6 +390185,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -389883,6 +390194,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -389906,6 +390218,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -389953,7 +390267,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -390188,7 +390501,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -390216,6 +390528,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -390417,9 +390730,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -390435,35 +390748,36 @@ }, { "session": { - "id": "harry-p", - "sourceId": "LXJJDW", - "title": "Harry P", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "hardware-security-from-sand-to-stone", + "sourceId": "UZDFEK", + "title": "Hardware Security: From Sand to Stone", + "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "TEE", + "Hardware Trojans" + ], + "tags": [ + "Decentralization", + "Hardware wallets", + "Security" + ], "language": "en", - "speakers": [], + "speakers": [ + "quintus-kilbourn" + ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE" + "slot_start": 1731575400000, + "slot_end": 1731576000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 6, 0, @@ -390847,6 +391161,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -391202,6 +391517,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -391303,6 +391619,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -391537,6 +391854,38 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -391730,36 +392079,10 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, + 0, 2, 0, 0, @@ -391778,39 +392101,27 @@ }, { "session": { - "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution", - "sourceId": "YQPADR", - "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution", - "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", + "id": "harry-p", + "sourceId": "LXJJDW", + "title": "Harry P", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Symbolic Execution", - "EVM" - ], - "tags": [ - "Security", - "Fuzzing", - "EVM", - "Fuzzing", - "Security" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "mate-soos" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731562200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8" + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE" }, "vector": [ - 6, 0, 0, 0, @@ -391820,6 +392131,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -392194,7 +392508,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -392548,8 +392861,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -392755,7 +393066,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -393110,10 +393420,13 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -393132,51 +393445,45 @@ }, { "session": { - "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders", - "sourceId": "RKR9EC", - "title": "How crypto is used in Africa today? Hear from leading builders", - "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution", + "sourceId": "YQPADR", + "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution", + "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Mass adoption", - "payment", - "P2P" + "Symbolic Execution", + "EVM" ], "tags": [ - "Use Cases", - "Remittance", - "Ethereum for Good", - "p2p", - "Ethereum for Good", - "Remittance", - "Use Cases" + "Security", + "Fuzzing", + "EVM", + "Fuzzing", + "Security" ], "language": "en", "speakers": [ - "yoseph-ayele", - "yele-bademosi", - "david-nandwa" + "mate-soos" ], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731654000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A" + "slot_start": 1731560400000, + "slot_end": 1731562200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -393555,8 +393862,6 @@ 0, 0, 6, - 6, - 6, 0, 0, 0, @@ -393911,6 +394216,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -393986,7 +394293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -394033,7 +394339,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -394120,6 +394425,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -394205,7 +394511,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -394272,7 +394577,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -394471,10 +394775,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -394486,58 +394790,60 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "how-crypto-solves-real-world-mev", - "sourceId": "WQBBFR", - "title": "How Crypto Solves Real World MEV", - "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders", + "sourceId": "RKR9EC", + "title": "How crypto is used in Africa today? Hear from leading builders", + "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Trusted", - "Execution", - "Environments" + "Mass adoption", + "payment", + "P2P" ], "tags": [ - "Use cases of cryptography", - "Use Cases", - "Environment", - "Mechanism design", - "trusted", - "execution", - "Mechanism design", "Use Cases", - "Use cases of cryptography" + "Remittance", + "Ethereum for Good", + "p2p", + "Ethereum for Good", + "Remittance", + "Use Cases" ], "language": "en", "speakers": [ - "matt-stephenson" + "yoseph-ayele", + "yele-bademosi", + "david-nandwa" ], "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg" + "slot_start": 1731650400000, + "slot_end": 1731654000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A" }, "vector": [ - 0, - 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -394917,6 +395223,8 @@ 0, 0, 6, + 6, + 6, 0, 0, 0, @@ -395273,50 +395581,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 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, @@ -395345,7 +395609,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395392,6 +395655,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -395461,11 +395725,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -395616,6 +395875,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -395632,7 +395892,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395682,6 +395941,55 @@ 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, @@ -395828,7 +396136,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395840,6 +396147,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -395850,42 +396160,43 @@ }, { "session": { - "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr", - "sourceId": "G7AHS9", - "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR", - "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.", - "track": "Developer Experience", + "id": "how-crypto-solves-real-world-mev", + "sourceId": "WQBBFR", + "title": "How Crypto Solves Real World MEV", + "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.", + "track": "Cryptoeconomics", "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "EVM", - "Hardhat", - "Optimism" + "Trusted", + "Execution", + "Environments" ], "tags": [ - "Layer 2s", - "Tooling", - "DevEx", - "optimism", - "DevEx", - "Layer 2s", - "Tooling" + "Use cases of cryptography", + "Use Cases", + "Environment", + "Mechanism design", + "trusted", + "execution", + "Mechanism design", + "Use Cases", + "Use cases of cryptography" ], "language": "en", "speakers": [ - "wodann" + "matt-stephenson" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA" + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg" }, "vector": [ - 0, 0, 0, 6, @@ -396632,6 +396943,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -396644,7 +396956,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -396689,7 +397000,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -396705,6 +397015,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396797,6 +397108,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396821,6 +397133,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396878,7 +397191,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -396990,6 +397302,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -397189,8 +397502,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -397207,48 +397520,45 @@ }, { "session": { - "id": "how-i-audit", - "sourceId": "3NRXP9", - "title": "How I Audit", - "description": "Dom, a former lead auditor at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review", - "track": "Security", - "type": "Workshop", - "expertise": "Expert", + "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr", + "sourceId": "G7AHS9", + "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR", + "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Solidity", - "Frameworks", - "Program analysis", - "Static Analysis" + "EVM", + "Hardhat", + "Optimism" ], "tags": [ + "Layer 2s", "Tooling", - "Security", - "Auditing", - "analysis", - "static", - "Auditing", - "Security", + "DevEx", + "optimism", + "DevEx", + "Layer 2s", "Tooling" ], "language": "en", "speakers": [ - "dominik-teiml" + "wodann" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731652200000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA" }, "vector": [ - 6, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -397982,11 +398292,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -398003,11 +398311,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -398016,6 +398324,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -398051,6 +398360,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -398134,7 +398444,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -398241,6 +398550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -398349,7 +398659,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -398548,6 +398857,9 @@ 0, 0, 2, + 0, + 0, + 0, 2, 0, 0, @@ -398566,44 +398878,48 @@ }, { "session": { - "id": "how-long-non-finality-could-kill-ethereum", - "sourceId": "U9E7PD", - "title": "How long non-finality could kill Ethereum", - "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "how-i-audit", + "sourceId": "3NRXP9", + "title": "How I Audit", + "description": "Dom, a former lead auditor at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review", + "track": "Security", + "type": "Workshop", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "-" + "Solidity", + "Frameworks", + "Program analysis", + "Static Analysis" ], "tags": [ - "Consensus", - "Decentralization", + "Tooling", "Security", - "Consensus", - "Decentralization", - "Security" + "Auditing", + "analysis", + "static", + "Auditing", + "Security", + "Tooling" ], "language": "en", "speakers": [ - "dapplion" + "dominik-teiml" ], "eventId": "devcon-7", - "slot_start": 1731568200000, - "slot_end": 1731570000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc" + "slot_start": 1731646800000, + "slot_end": 1731652200000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ" }, "vector": [ + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -399336,9 +399652,10 @@ 0, 0, 0, - 6, 0, 0, + 6, + 0, 0, 0, 6, @@ -399358,6 +399675,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399438,8 +399756,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -399490,6 +399806,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399704,6 +400021,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399898,11 +400216,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -399920,40 +400238,36 @@ }, { "session": { - "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality", - "sourceId": "89M7ME", - "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality", - "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols", + "id": "how-long-non-finality-could-kill-ethereum", + "sourceId": "U9E7PD", + "title": "How long non-finality could kill Ethereum", + "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?", "track": "Core Protocol", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "model checking", - "TLA+", - "Apalache" + "-" ], "tags": [ "Consensus", - "Protocol Design", - "Formal Verification", - "apalache", + "Decentralization", + "Security", "Consensus", - "Formal Verification", - "Protocol Design" + "Decentralization", + "Security" ], "language": "en", "speakers": [ - "igor-konnov", - "thanh-hai-tran" + "dapplion" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731642000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk" + "slot_start": 1731568200000, + "slot_end": 1731570000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc" }, "vector": [ 0, @@ -400118,7 +400432,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -400314,7 +400627,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -400349,6 +400661,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -400695,6 +401009,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -400740,7 +401055,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -400797,6 +401111,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -400891,7 +401206,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -401062,7 +401376,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -401256,9 +401569,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 2, @@ -401273,51 +401587,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "how-much-security-does-your-restaking-protocol-really-need", - "sourceId": "QDDV9C", - "title": "How much security does your restaking protocol really need?", - "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Expert", + "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality", + "sourceId": "89M7ME", + "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality", + "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Matching Markets", - "Proof of Stake" + "model checking", + "TLA+", + "Apalache" ], "tags": [ - "Staking", - "Censorship Resistance", - "Economics", - "Restaking", - "proof-of", - "Censorship Resistance", - "Economics", - "Restaking" + "Consensus", + "Protocol Design", + "Formal Verification", + "apalache", + "Consensus", + "Formal Verification", + "Protocol Design" ], "language": "en", "speakers": [ - "tarun-chitra" + "igor-konnov", + "thanh-hai-tran" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4" + "slot_start": 1731641400000, + "slot_end": 1731642000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk" }, "vector": [ 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -401475,6 +401791,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -401670,6 +401987,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -401705,7 +402023,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -402056,6 +402373,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -402086,7 +402404,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -402097,6 +402414,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -402180,7 +402498,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -402199,8 +402516,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -402252,6 +402567,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -402421,8 +402737,6 @@ 0, 0, 2, - 2, - 0, 0, 0, 0, @@ -402618,6 +402932,9 @@ 0, 2, 0, + 0, + 0, + 0, 2, 0, 0, @@ -402635,44 +402952,44 @@ }, { "session": { - "id": "how-to-audit-smart-contract-languages-brief-intro", - "sourceId": "HMYRTU", - "title": "How to Audit Smart Contract Languages: Brief Intro", - "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "how-much-security-does-your-restaking-protocol-really-need", + "sourceId": "QDDV9C", + "title": "How much security does your restaking protocol really need?", + "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Expert", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Language", - "Security" + "Matching Markets", + "Proof of Stake" ], "tags": [ - "Languages", - "Security", - "Auditing", - "language", - "Auditing", - "Languages", - "Security" + "Staking", + "Censorship Resistance", + "Economics", + "Restaking", + "proof-of", + "Censorship Resistance", + "Economics", + "Restaking" ], "language": "en", "speakers": [ - "nicolas-garcia" + "tarun-chitra" ], "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731656400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY" + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4" }, "vector": [ - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -403407,7 +403724,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -403445,6 +403761,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -403504,7 +403821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -403539,6 +403855,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -403557,9 +403874,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -403779,6 +404096,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -403969,13 +404287,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -403991,42 +404310,41 @@ }, { "session": { - "id": "how-to-coordinate-an-epistemic-revolution", - "sourceId": "DNJMER", - "title": "How to coordinate an epistemic revolution", - "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", + "id": "how-to-audit-smart-contract-languages-brief-intro", + "sourceId": "HMYRTU", + "title": "How to Audit Smart Contract Languages: Brief Intro", + "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Semantic Governance", - "Identity", - "Citizens Assembly" + "Language", + "Security" ], "tags": [ - "Consensus", - "Quadratic Voting", - "Collective Intelligence", - "citizens", - "assembly", - "Collective Intelligence", - "Consensus", - "Quadratic Voting" + "Languages", + "Security", + "Auditing", + "language", + "Auditing", + "Languages", + "Security" ], "language": "en", "speakers": [ - "nick-almond" + "nicolas-garcia" ], "eventId": "devcon-7", - "slot_start": 1731643800000, - "slot_end": 1731645600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4" + "slot_start": 1731655800000, + "slot_end": 1731656400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY" }, "vector": [ + 6, 0, 0, 0, @@ -404038,8 +404356,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -404767,10 +405083,11 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -404799,7 +405116,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -404864,6 +405180,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -404918,6 +405235,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -404974,7 +405292,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -405138,7 +405455,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -405332,6 +405648,8 @@ 2, 0, 0, + 0, + 0, 2, 0, 0, @@ -405349,39 +405667,40 @@ }, { "session": { - "id": "how-to-destroy-a-network-offboarding-the-mainstream", - "sourceId": "XNCFRL", - "title": "How To Destroy A Network: Offboarding The Mainstream", - "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.", - "track": "Cypherpunk & Privacy", + "id": "how-to-coordinate-an-epistemic-revolution", + "sourceId": "DNJMER", + "title": "How to coordinate an epistemic revolution", + "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.", + "track": "Coordination", "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Values" + "Semantic Governance", + "Identity", + "Citizens Assembly" ], "tags": [ - "Network State", - "Privacy", - "Anonymity", - "Digital Sovereignty", - "value", - "Anonymity", - "Digital Sovereignty", - "Network State", - "Privacy" + "Consensus", + "Quadratic Voting", + "Collective Intelligence", + "citizens", + "assembly", + "Collective Intelligence", + "Consensus", + "Quadratic Voting" ], "language": "en", "speakers": [ - "laurence-day" + "nick-almond" ], "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731486000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc" + "slot_start": 1731643800000, + "slot_end": 1731645600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4" }, "vector": [ 0, @@ -405389,14 +405708,13 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -406129,6 +406447,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -406148,20 +406467,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -406169,7 +406474,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -406239,13 +406543,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -406356,6 +406653,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -406496,7 +406794,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -406517,6 +406814,20 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -406684,7 +406995,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -406693,6 +407003,12 @@ 0, 0, 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -406701,47 +407017,48 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "how-to-do-something-to-some-state-in-some-contract", - "sourceId": "HECBJV", - "title": "How to do something to some state in some contract", - "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.", - "track": "Applied Cryptography", - "type": "Workshop", + "id": "how-to-destroy-a-network-offboarding-the-mainstream", + "sourceId": "XNCFRL", + "title": "How To Destroy A Network: Offboarding The Mainstream", + "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.", + "track": "Cypherpunk & Privacy", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "ZKDSL", - "DevOps", - "Mobile Proving" + "Values" ], "tags": [ - "DevEx", + "Network State", "Privacy", - "Decentralization", - "Cryptography", - "Mobile", - "proving", - "Cryptography", - "Decentralization", - "DevEx", + "Anonymity", + "Digital Sovereignty", + "value", + "Anonymity", + "Digital Sovereignty", + "Network State", "Privacy" ], "language": "en", "speakers": [ - "jose-pedro-sousa-or-zpedro" + "laurence-day" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731644100000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc" + "slot_start": 1731484200000, + "slot_end": 1731486000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc" }, "vector": [ 0, @@ -406749,13 +407066,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -407495,7 +407811,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -407505,7 +407820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -407533,7 +407847,10 @@ 0, 0, 0, + 2, + 0, 0, + 2, 0, 0, 0, @@ -407584,7 +407901,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -407597,12 +407913,12 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -407858,6 +408174,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -408048,12 +408366,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -408066,33 +408384,42 @@ }, { "session": { - "id": "how-to-hallucinate-a-server", - "sourceId": "QNFTYG", - "title": "How To Hallucinate A Server", - "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.", + "id": "how-to-do-something-to-some-state-in-some-contract", + "sourceId": "HECBJV", + "title": "How to do something to some state in some contract", + "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.", "track": "Applied Cryptography", - "type": "Talk", + "type": "Workshop", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "MPFHE", - "Hallucinated Server" + "ZKDSL", + "DevOps", + "Mobile Proving" ], "tags": [ - "Homomorphic Encryption", - "MPC" + "DevEx", + "Privacy", + "Decentralization", + "Cryptography", + "Mobile", + "proving", + "Cryptography", + "Decentralization", + "DevEx", + "Privacy" ], "language": "en", "speakers": [ - "gubsheep" + "jose-pedro-sousa-or-zpedro" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk" + "slot_start": 1731638700000, + "slot_end": 1731644100000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc" }, "vector": [ 0, @@ -408282,10 +408609,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -408495,6 +408818,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -408850,6 +409174,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -408859,12 +409184,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -408922,8 +409249,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -408938,6 +409263,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -408950,7 +409276,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -409417,39 +409745,33 @@ }, { "session": { - "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography", - "sourceId": "SDPVVF", - "title": "How to onboard 22 million users overnight using non-conventional cryptography", - "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.", - "track": "Real World Ethereum", - "type": "Lightning Talk", + "id": "how-to-hallucinate-a-server", + "sourceId": "QNFTYG", + "title": "How To Hallucinate A Server", + "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "ERC-4337", - "RSA", - "PKI" + "MPFHE", + "Hallucinated Server" ], "tags": [ - "Identity", - "Cryptography", - "Account Abstraction", - "pki", - "Account Abstraction", - "Cryptography", - "Identity" + "Homomorphic Encryption", + "MPC" ], "language": "en", "speakers": [ - "ernesto-garcia" + "gubsheep" ], "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731480000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c" + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk" }, "vector": [ 0, @@ -409458,11 +409780,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -409563,7 +409886,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -409639,6 +409961,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -410203,7 +410528,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -410239,9 +410563,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -410280,6 +410602,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -410565,7 +410889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -410756,12 +411079,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -410774,46 +411097,47 @@ }, { "session": { - "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data", - "sourceId": "UASADN", - "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data", - "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.", - "track": "Core Protocol", + "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography", + "sourceId": "SDPVVF", + "title": "How to onboard 22 million users overnight using non-conventional cryptography", + "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Gas limit", - "State growth", - "History growth", - "Bandwidth" + "ERC-4337", + "RSA", + "PKI" ], "tags": [ - "Layer 1", - "Gas", - "Scalability", - "bandwidth", - "Gas", - "Layer 1", - "Scalability" + "Identity", + "Cryptography", + "Account Abstraction", + "pki", + "Account Abstraction", + "Cryptography", + "Identity" ], "language": "en", "speakers": [ - "storm-slivkoff" + "ernesto-garcia" ], "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731570000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE" + "slot_start": 1731479400000, + "slot_end": 1731480000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c" }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -410919,6 +411243,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -411207,7 +411532,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -411560,10 +411884,12 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -411594,6 +411920,21 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -411688,7 +412029,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -411776,24 +412116,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, @@ -412110,16 +412432,17 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -412132,47 +412455,47 @@ }, { "session": { - "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes", - "sourceId": "TJ833L", - "title": "How to steal $1.1M from lending market in 15 minutes", - "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.", - "track": "Security", + "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data", + "sourceId": "UASADN", + "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data", + "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.", + "track": "Core Protocol", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "defi", - "lending protocols", - "exploit" + "Gas limit", + "State growth", + "History growth", + "Bandwidth" ], "tags": [ - "Security", - "Auditing", - "Bug", - "exploits", - "Auditing", - "Bug", - "Security" + "Layer 1", + "Gas", + "Scalability", + "bandwidth", + "Gas", + "Layer 1", + "Scalability" ], "language": "en", "speakers": [ - "bartosz-barwikowski" + "storm-slivkoff" ], "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731658200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM" + "slot_start": 1731569400000, + "slot_end": 1731570000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE" }, "vector": [ - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -412905,7 +413228,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -412923,6 +413245,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -413047,6 +413370,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -413057,7 +413381,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -413137,6 +413460,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -413179,7 +413504,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -413467,12 +413791,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -413489,46 +413814,48 @@ }, { "session": { - "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy", - "sourceId": "GFAA97", - "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.", - "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.", - "track": "Real World Ethereum", - "type": "Talk", + "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes", + "sourceId": "TJ833L", + "title": "How to steal $1.1M from lending market in 15 minutes", + "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.", + "track": "Security", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Business", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Web3" + "defi", + "lending protocols", + "exploit" ], "tags": [ - "RWA", - "Economics", - "web3", - "Economics", - "RWA" + "Security", + "Auditing", + "Bug", + "exploits", + "Auditing", + "Bug", + "Security" ], "language": "en", "speakers": [ - "justin-banon", - "jason-potts" + "bartosz-barwikowski" ], "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU" + "slot_start": 1731657600000, + "slot_end": 1731658200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -413921,7 +414248,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -414262,6 +414588,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -414294,7 +414622,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -414536,6 +414863,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -414821,14 +415149,15 @@ 0, 0, 0, + 0, 2, 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -414843,46 +415172,45 @@ }, { "session": { - "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef", - "sourceId": "7SXGVX", - "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)", - "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.", + "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy", + "sourceId": "GFAA97", + "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.", + "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.", "track": "Real World Ethereum", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Business", "featured": false, "doNotRecord": false, - "keywords": [ - "real", - "world", - "usecases" - ], "tags": [ - "Free Speech", - "Not financial", - "Public good", - "Quadratic Voting", - "Use Cases" + "RWA", + "Economics", + "web3", + "Economics", + "RWA" ], - "language": "en", - "speakers": [ - "team-next-billion-ef", - "david-uzochukwu", - "eddie-kago", - "guo-liu", - "mercedes-rodriguez-simon", - "valeriia-panina", - "karam-alhamad", - "tomislav-mamic", - "rebecca-mqamelo", - "lefteris-arapakis" + "keywords": [ + "Web3" ], + "duration": 1461, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "yuEFLaSk7us", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731497400000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI" + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU", + "resources_slides": null, + "speakers": [ + "justin-banon", + "jason-potts" + ] }, "vector": [ 0, @@ -414964,7 +415292,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -415253,7 +415580,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -415288,12 +415614,23 @@ 0, 6, 6, - 6, - 6, - 6, - 6, - 6, - 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -415702,7 +416039,44 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -415832,48 +416206,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, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -415998,6 +416330,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -416181,6 +416514,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -416194,11 +416528,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -416207,53 +416536,55 @@ }, { "session": { - "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations", - "sourceId": "UQ8MWW", - "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations", - "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!", - "track": "Core Protocol", + "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef", + "sourceId": "7SXGVX", + "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)", + "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.", + "track": "Real World Ethereum", "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": true, + "expertise": "Beginner", + "audience": "Community", + "featured": false, "doNotRecord": false, "keywords": [ - "Python", - "Pytest", - "Specs" + "real", + "world", + "usecases" ], "tags": [ - "Core Protocol", - "Security", - "Testing", - "python", - "pytest", - "specs", - "Core Protocol", - "Security", - "Testing" + "Free Speech", + "Not financial", + "Public good", + "Quadratic Voting", + "Use Cases" ], "language": "en", "speakers": [ - "mario-vega", - "danceratopz", - "dimitry-kh", - "spencer-taylor-brown" + "team-next-billion-ef", + "david-uzochukwu", + "eddie-kago", + "guo-liu", + "mercedes-rodriguez-simon", + "valeriia-panina", + "karam-alhamad", + "tomislav-mamic", + "rebecca-mqamelo", + "lefteris-arapakis" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731479400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag" + "slot_start": 1731486600000, + "slot_end": 1731497400000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -416326,6 +416657,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -416614,6 +416946,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -416646,6 +416979,14 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -416656,10 +416997,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -416985,7 +417322,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -417004,11 +417340,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -417060,6 +417396,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -417089,6 +417426,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -417190,6 +417528,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -417217,6 +417556,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -417227,7 +417567,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -417364,11 +417703,6 @@ 0, 0, 0, - 2, - 2, - 2, - 0, - 0, 0, 0, 0, @@ -417551,12 +417885,10 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -417569,44 +417901,50 @@ }, { "session": { - "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know", - "sourceId": "V8FHZL", - "title": "I read every single 1990s Cypherpunk email. Here's what you should know.", - "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, + "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations", + "sourceId": "UQ8MWW", + "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations", + "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": true, "doNotRecord": false, "keywords": [ - "Cypherpunk" + "Python", + "Pytest", + "Specs" ], "tags": [ - "Permissionless", - "Free Speech", - "Censorship Resistance", - "cypherpunk", - "Censorship Resistance", - "Free Speech", - "Permissionless" + "Core Protocol", + "Security", + "Testing", + "python", + "pytest", + "specs", + "Core Protocol", + "Security", + "Testing" ], "language": "en", "speakers": [ - "porter-adams" + "mario-vega", + "danceratopz", + "dimitry-kh", + "spencer-taylor-brown" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA" + "slot_start": 1731472200000, + "slot_end": 1731479400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -418012,9 +418350,9 @@ 0, 0, 0, - 0, - 0, - 0, + 6, + 6, + 6, 6, 0, 0, @@ -418342,6 +418680,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -418360,6 +418699,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418367,8 +418707,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -418488,7 +418826,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -418532,7 +418869,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -418587,6 +418923,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418723,7 +419060,8 @@ 0, 0, 2, - 0, + 2, + 2, 0, 0, 0, @@ -418908,10 +419246,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -418924,34 +419264,37 @@ }, { "session": { - "id": "impossibility-within-dynamically-available-protocols", - "sourceId": "SUNDNH", - "title": "Impossibility within Dynamically Available Protocols", - "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Academic", + "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know", + "sourceId": "V8FHZL", + "title": "I read every single 1990s Cypherpunk email. Here's what you should know.", + "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Dynamic", - "Availability" + "Cypherpunk" ], "tags": [ - "Consensus Mechanisms", - "Finality", - "Single-slot Finality" + "Permissionless", + "Free Speech", + "Censorship Resistance", + "cypherpunk", + "Censorship Resistance", + "Free Speech", + "Permissionless" ], "language": "en", "speakers": [ - "yash-saraswat" + "porter-adams" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489300000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc" + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA" }, "vector": [ 0, @@ -418959,6 +419302,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -418969,8 +419313,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -419721,6 +420063,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -419841,8 +420184,7 @@ 0, 0, 0, - 0, - 0, + 2, 0, 0, 0, @@ -420075,7 +420417,7 @@ 0, 0, 0, - 2, + 0, 2, 0, 0, @@ -420257,6 +420599,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -420264,10 +420607,11 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -420276,43 +420620,34 @@ }, { "session": { - "id": "improving-the-user-experience-by-user-research", - "sourceId": "ZVUFEY", - "title": "Improving the User Experience by User Research.", - "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.", - "track": "Usability", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Product", + "id": "impossibility-within-dynamically-available-protocols", + "sourceId": "SUNDNH", + "title": "Impossibility within Dynamically Available Protocols", + "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "Customer Journey Map", - "In-depth interviews", - "Blockchain Mass Adoption." + "Dynamic", + "Availability" ], "tags": [ - "User Experience", - "Interface", - "Accessibility", - "User Research", - "adoption", - "blockchain", - "mass", - "Accessibility", - "Interface", - "User Experience", - "User Research" + "Consensus Mechanisms", + "Finality", + "Single-slot Finality" ], "language": "en", "speakers": [ - "andrii-bondar" + "yash-saraswat" ], "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731394800000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0" + "slot_start": 1731488400000, + "slot_end": 1731489300000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc" }, "vector": [ 0, @@ -420323,8 +420658,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -420332,6 +420665,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -421069,7 +421403,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -421113,7 +421446,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421140,7 +421472,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421195,7 +421526,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421211,8 +421541,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -421252,12 +421580,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -421442,6 +421772,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -421617,7 +421949,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421632,44 +421963,53 @@ 0, 0, 0, + 0, + 2, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "incentivizing-defensive-technologies-for-ethereum", - "sourceId": "HTNYKL", - "title": "Incentivizing Defensive Technologies for Ethereum", - "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.", - "track": "Real World Ethereum", - "type": "Lightning Talk", + "id": "improving-the-user-experience-by-user-research", + "sourceId": "ZVUFEY", + "title": "Improving the User Experience by User Research.", + "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.", + "track": "Usability", + "type": "Workshop", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc", - "defensive technologies" + "Customer Journey Map", + "In-depth interviews", + "Blockchain Mass Adoption." ], "tags": [ - "Regenative Ethereum", - "Ethereum for Good", - "e/acc", - "technology", - "defense", - "e/acc", - "Ethereum for Good", - "Regenative Ethereum" + "User Experience", + "Interface", + "Accessibility", + "User Research", + "adoption", + "blockchain", + "mass", + "Accessibility", + "Interface", + "User Experience", + "User Research" ], "language": "en", "speakers": [ - "han-tuzun" + "andrii-bondar" ], "eventId": "devcon-7", - "slot_start": 1731658200000, - "slot_end": 1731658800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg" + "slot_start": 1731389400000, + "slot_end": 1731394800000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0" }, "vector": [ 0, @@ -421678,10 +422018,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -422428,6 +422767,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -422471,6 +422811,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -422497,6 +422838,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -422536,7 +422878,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -422552,6 +422893,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -422566,8 +422908,9 @@ 0, 0, 0, - 2, 0, + 2, + 2, 0, 0, 0, @@ -422609,6 +422952,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -422795,9 +423139,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -422976,11 +423317,11 @@ 0, 2, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -422994,25 +423335,39 @@ }, { "session": { - "id": "inch", - "sourceId": "AWQHPU", - "title": "INCH", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "incentivizing-defensive-technologies-for-ethereum", + "sourceId": "HTNYKL", + "title": "Incentivizing Defensive Technologies for Ethereum", + "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "d/acc", + "defensive technologies" + ], + "tags": [ + "Regenative Ethereum", + "Ethereum for Good", + "e/acc", + "technology", + "defense", + "e/acc", + "Ethereum for Good", + "Regenative Ethereum" + ], "language": "en", - "speakers": [], + "speakers": [ + "han-tuzun" + ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731583800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw" + "slot_start": 1731658200000, + "slot_end": 1731658800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg" }, "vector": [ 0, @@ -423021,9 +423376,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -423434,6 +423786,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -423882,6 +424235,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -423911,6 +424265,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -424139,7 +424494,9 @@ 0, 0, 0, - 0, + 2, + 2, + 2, 0, 0, 0, @@ -424318,7 +424675,6 @@ 0, 2, 0, - 0, 2, 0, 0, @@ -424337,39 +424693,34 @@ }, { "session": { - "id": "inclusion-list-inevitable-tradeoffs", - "sourceId": "XEE9EG", - "title": "Inclusion List Inevitable Tradeoffs", - "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "inch", + "sourceId": "AWQHPU", + "title": "INCH", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "inclusion", - "list" - ], - "tags": [ - "Decentralization Improvements", - "Censorship Resistance", - "inclusivity", - "lists", - "Censorship Resistance", - "Decentralization Improvements" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "terence" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731490200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc" + "slot_start": 1731580200000, + "slot_end": 1731583800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 6, @@ -424710,7 +425061,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -425114,7 +425464,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -425256,7 +425605,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -425496,29 +425844,25 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -425674,6 +426018,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -425692,42 +426037,39 @@ }, { "session": { - "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours", - "sourceId": "QEDEUG", - "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours", - "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.", - "track": "Developer Experience", + "id": "inclusion-list-inevitable-tradeoffs", + "sourceId": "XEE9EG", + "title": "Inclusion List Inevitable Tradeoffs", + "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.", + "track": "Cryptoeconomics", "type": "Lightning Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Data", - "Processing" + "inclusion", + "list" ], "tags": [ - "Architecture", - "Scalability", - "Event monitoring", - "data", - "processor", - "Architecture", - "Event monitoring", - "Scalability" + "Decentralization Improvements", + "Censorship Resistance", + "inclusivity", + "lists", + "Censorship Resistance", + "Decentralization Improvements" ], "language": "en", "speakers": [ - "panjamapong-panj-sermsawatsri" + "terence" ], "eventId": "devcon-7", - "slot_start": 1731492600000, - "slot_end": 1731493200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI" + "slot_start": 1731489600000, + "slot_end": 1731490200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc" }, "vector": [ - 0, 0, 0, 6, @@ -426068,6 +426410,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -426144,7 +426487,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -426473,6 +426815,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -426527,7 +426870,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -426605,7 +426947,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -426616,6 +426957,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -426717,7 +427061,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -426775,7 +427118,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -426856,6 +427198,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -427027,12 +427370,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -427049,39 +427393,39 @@ }, { "session": { - "id": "indexing-ethereum-when-and-how-to-build-an-indexer", - "sourceId": "BGGFDD", - "title": "Indexing Ethereum: When and How to Build an Indexer", - "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.", + "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours", + "sourceId": "QEDEUG", + "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours", + "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.", "track": "Developer Experience", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "database", - "indexing", - "infrastructure" + "Data", + "Processing" ], "tags": [ "Architecture", - "Developer Infrastructure", - "Best Practices", - "infrastructure", + "Scalability", + "Event monitoring", + "data", + "processor", "Architecture", - "Best Practices", - "Developer Infrastructure" + "Event monitoring", + "Scalability" ], "language": "en", "speakers": [ - "ryan-smith" + "panjamapong-panj-sermsawatsri" ], "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731483000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E" + "slot_start": 1731492600000, + "slot_end": 1731493200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI" }, "vector": [ 0, @@ -427501,7 +427845,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -427853,7 +428196,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -427876,7 +428218,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -427884,11 +428225,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -427965,6 +428307,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -428010,7 +428353,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428078,6 +428420,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -428135,6 +428478,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -428213,6 +428557,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -428406,40 +428751,46 @@ }, { "session": { - "id": "indistinguishability-obfuscation-io", - "sourceId": "KDUKFD", - "title": "Indistinguishability Obfuscation (iO)", - "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", + "id": "indexing-ethereum-when-and-how-to-build-an-indexer", + "sourceId": "BGGFDD", + "title": "Indexing Ethereum: When and How to Build an Indexer", + "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.", + "track": "Developer Experience", + "type": "Talk", "expertise": "Intermediate", - "audience": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Programmable Cryptography", - "iO" + "database", + "indexing", + "infrastructure" ], "tags": [ - "Cryptography" + "Architecture", + "Developer Infrastructure", + "Best Practices", + "infrastructure", + "Architecture", + "Best Practices", + "Developer Infrastructure" ], "language": "en", "speakers": [ - "barry", - "tianyao-gu", - "brian-lawrence", - "janmajaya-mall" + "ryan-smith" ], "eventId": "devcon-7", - "slot_start": 1731654900000, - "slot_end": 1731660300000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk" + "slot_start": 1731481200000, + "slot_end": 1731483000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E" }, "vector": [ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -428451,7 +428802,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -428629,7 +428979,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -428817,7 +429166,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -428856,7 +429204,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -429188,7 +429535,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -429210,6 +429556,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429232,6 +429579,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429239,6 +429587,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429364,6 +429713,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429741,6 +430091,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429751,7 +430102,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -429759,41 +430109,47 @@ }, { "session": { - "id": "insights-from-block-propagation-in-the-ethereum-p2p-network", - "sourceId": "T8GXPY", - "title": "Insights from block propagation in the Ethereum P2P network", - "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!", - "track": "Core Protocol", - "type": "Lightning Talk", + "id": "indistinguishability-obfuscation-io", + "sourceId": "KDUKFD", + "title": "Indistinguishability Obfuscation (iO)", + "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Research", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "Block Propagation", - "Networking Protocols" + "Programmable Cryptography", + "iO" ], "tags": [ - "Core Protocol", - "Architecture", - "Scalability", - "network", - "protocol", - "Architecture", - "Core Protocol", - "Scalability" + "Cryptography" ], "language": "en", "speakers": [ - "mikel-cortes-cortze" + "barry", + "tianyao-gu", + "brian-lawrence", + "janmajaya-mall" ], "eventId": "devcon-7", - "slot_start": 1731570600000, - "slot_end": 1731571200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE" + "slot_start": 1731654900000, + "slot_end": 1731660300000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -429976,6 +430332,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -430162,6 +430520,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -430199,6 +430559,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -430215,7 +430577,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -430531,6 +430892,23 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -430551,7 +430929,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -430594,7 +430971,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -430620,7 +430996,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -430672,7 +431047,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -430923,33 +431297,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, @@ -431099,7 +431446,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -431109,6 +431455,7 @@ 0, 0, 0, + 2, 0, 0, 0 @@ -431116,50 +431463,49 @@ }, { "session": { - "id": "interoperability-between-l2s-latest-developments-framework-and-challenges", - "sourceId": "3ZH9ST", - "title": "Interoperability between L2s: Latest developments, Framework and Challenges", - "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.", - "track": "Layer 2", + "id": "insights-from-block-propagation-in-the-ethereum-p2p-network", + "sourceId": "T8GXPY", + "title": "Insights from block propagation in the Ethereum P2P network", + "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!", + "track": "Core Protocol", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Composability", - "Interoperability" + "Block Propagation", + "Networking Protocols" ], "tags": [ - "Fragmentation", - "Cross-L2", - "Developer Infrastructure", - "interoperability", - "Cross-L2", - "Developer Infrastructure", - "Fragmentation" + "Core Protocol", + "Architecture", + "Scalability", + "network", + "protocol", + "Architecture", + "Core Protocol", + "Scalability" ], "language": "en", "speakers": [ - "marshall-vyletel-jr", - "wei-dai" + "mikel-cortes-cortze" ], "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek" + "slot_start": 1731570600000, + "slot_end": 1731571200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -431574,7 +431920,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -431911,6 +432256,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -431932,7 +432279,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -431943,7 +432289,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -431954,6 +432299,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -431979,6 +432325,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -432030,6 +432377,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -432089,7 +432437,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -432451,12 +432798,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -432473,46 +432821,49 @@ }, { "session": { - "id": "interpreting-solidity", - "sourceId": "GQAEZX", - "title": "Interpreting Solidity", - "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so", - "track": "Developer Experience", - "type": "Talk", + "id": "interoperability-between-l2s-latest-developments-framework-and-challenges", + "sourceId": "3ZH9ST", + "title": "Interoperability between L2s: Latest developments, Framework and Challenges", + "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.", + "track": "Layer 2", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Developper", + "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "NA" + "Composability", + "Interoperability" ], "tags": [ + "Fragmentation", + "Cross-L2", "Developer Infrastructure", - "Tooling", - "Languages", + "interoperability", + "Cross-L2", "Developer Infrastructure", - "Languages", - "Tooling" + "Fragmentation" ], "language": "en", "speakers": [ - "daniel-perez" + "marshall-vyletel-jr", + "wei-dai" ], "eventId": "devcon-7", - "slot_start": 1731578400000, + "slot_start": 1731579600000, "slot_end": 1731580200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM" + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -432927,9 +433278,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -433264,7 +433616,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -433287,6 +433638,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433340,8 +433692,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -433447,6 +433797,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433636,6 +433987,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433809,6 +434161,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433817,7 +434170,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -433827,44 +434179,42 @@ }, { "session": { - "id": "introducing-provable-object-data", - "sourceId": "YP9HRR", - "title": "Introducing Provable Object Data", - "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.", - "track": "Applied Cryptography", + "id": "interpreting-solidity", + "sourceId": "GQAEZX", + "title": "Interpreting Solidity", + "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so", + "track": "Developer Experience", "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Zupass", - "developers", - "POD" + "NA" ], "tags": [ - "Libraries", - "Zero-Knowledge", - "Use cases of cryptography", - "pod", - "Libraries", - "Use cases of cryptography", - "Zero-Knowledge" + "Developer Infrastructure", + "Tooling", + "Languages", + "Developer Infrastructure", + "Languages", + "Tooling" ], "language": "en", "speakers": [ - "andrew-twyman" + "daniel-perez" ], "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo" + "slot_start": 1731578400000, + "slot_end": 1731580200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -433872,7 +434222,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -433885,7 +434234,6 @@ 0, 0, 0, - 4, 0, 0, 0, @@ -434287,6 +434635,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -434611,8 +434960,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -434624,11 +434971,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -434657,6 +435004,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434699,6 +435047,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434993,7 +435342,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -435168,7 +435516,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -435177,6 +435524,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0 @@ -435184,38 +435534,39 @@ }, { "session": { - "id": "introduction-to-hash-based-proof-systems", - "sourceId": "EUAERD", - "title": "Introduction to hash-based proof systems", - "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.", + "id": "introducing-provable-object-data", + "sourceId": "YP9HRR", + "title": "Introducing Provable Object Data", + "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.", "track": "Applied Cryptography", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Binius", - "Reed-Solomon" + "Zupass", + "developers", + "POD" ], "tags": [ - "Scalability", - "ZKP", - "STARK", - "reed-solomon", - "Scalability", - "STARK", - "ZKP" + "Libraries", + "Zero-Knowledge", + "Use cases of cryptography", + "pod", + "Libraries", + "Use cases of cryptography", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "diego-kingston" + "andrew-twyman" ], "eventId": "devcon-7", - "slot_start": 1731392400000, - "slot_end": 1731393000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU" + "slot_start": 1731569400000, + "slot_end": 1731571200000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo" }, "vector": [ 0, @@ -435241,6 +435592,7 @@ 0, 0, 0, + 4, 0, 0, 0, @@ -435643,7 +435995,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -435968,6 +436319,24 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -436031,7 +436400,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -436096,7 +436464,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -436167,22 +436534,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -436520,12 +436871,13 @@ 0, 0, 0, - 2, 0, 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -436540,42 +436892,38 @@ }, { "session": { - "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc", - "sourceId": "VYD38F", - "title": "Introduction to Multilateral Trade Credit Set-off in MPC", - "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms", + "id": "introduction-to-hash-based-proof-systems", + "sourceId": "EUAERD", + "title": "Introduction to hash-based proof systems", + "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.", "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "finance" - ], "keywords": [ - "MPC", - "cryptography", - "finance" + "Binius", + "Reed-Solomon" + ], + "tags": [ + "Scalability", + "ZKP", + "STARK", + "reed-solomon", + "Scalability", + "STARK", + "ZKP" ], - "duration": 680, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "OCEEe8azbR8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "diego-kingston" + ], "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731391800000, + "slot_start": 1731392400000, + "slot_end": 1731393000000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls", - "resources_slides": null, - "speakers": [ - "enrico-bottazzi" - ] + "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU" }, "vector": [ 0, @@ -437003,7 +437351,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -437393,6 +437740,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -437457,6 +437805,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -437529,8 +437878,7 @@ 0, 0, 0, - 0, - 0, + 2, 0, 0, 0, @@ -437878,12 +438226,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -437900,27 +438249,42 @@ }, { "session": { - "id": "io", - "sourceId": "9BQWGB", - "title": "iO", - "description": "It will be worth it ;)", + "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc", + "sourceId": "VYD38F", + "title": "Introduction to Multilateral Trade Credit Set-off in MPC", + "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms", "track": "Applied Cryptography", - "type": "Talk", - "expertise": "", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "barry-whitehat" + "tags": [ + "finance" + ], + "keywords": [ + "MPC", + "cryptography", + "finance" ], + "duration": 680, + "language": "en", + "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb", + "sources_youtubeId": "OCEEe8azbR8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA" + "slot_start": 1731391200000, + "slot_end": 1731391800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls", + "resources_slides": null, + "speakers": [ + "enrico-bottazzi" + ] }, "vector": [ 0, @@ -438349,7 +438713,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -439058,6 +439421,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -439227,6 +439591,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -439245,44 +439610,31 @@ }, { "session": { - "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data", - "sourceId": "E3JADX", - "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data", - "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "io", + "sourceId": "9BQWGB", + "title": "iO", + "description": "It will be worth it ;)", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Multi-block MEV", - "Data Analysis" - ], - "tags": [ - "Economics", - "Tokenomics", - "MEV", - "data", - "analysis", - "Economics", - "MEV", - "Tokenomics" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "pascal-stichler" + "barry-whitehat" ], "eventId": "devcon-7", - "slot_start": 1731639300000, - "slot_end": 1731639900000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M" + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA" }, "vector": [ 0, 0, - 6, 0, 0, 0, @@ -439291,6 +439643,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -439321,7 +439675,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -439707,6 +440060,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -440020,9 +440375,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -440053,7 +440406,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -440062,7 +440414,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -440328,7 +440679,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -440580,11 +440930,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -440597,46 +440950,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "issuance-endgame-stake-targeting", - "sourceId": "39HYEG", - "title": "Issuance Endgame: Stake Targeting", - "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like. \r\n\r\nWe argue that it should include an issuance policy that targets a range of staking ratios instead. The intention is to be secure enough but avoid overpaying for security and thereby enabling said negative externalities.", - "track": "Core Protocol", - "type": "Talk", + "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data", + "sourceId": "E3JADX", + "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data", + "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "none" + "Multi-block MEV", + "Data Analysis" ], "tags": [ - "ACD", - "Staking", "Economics", - "ACD", + "Tokenomics", + "MEV", + "data", + "analysis", "Economics", - "Staking" + "MEV", + "Tokenomics" ], "language": "en", "speakers": [ - "caspar-schwarz-schilling", - "ansgar-dietrichs" + "pascal-stichler" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, + "slot_start": 1731639300000, + "slot_end": 1731639900000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8" + "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M" }, "vector": [ - 0, - 0, 0, 0, 6, @@ -440678,19 +441032,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -441063,24 +441404,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -441408,10 +441731,10 @@ 0, 0, 0, - 2, - 0, 0, + 6, 0, + 6, 0, 0, 0, @@ -441442,6 +441765,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -441450,6 +441774,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -441502,7 +441827,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -441659,7 +441983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -441718,6 +442041,40 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -441957,32 +442314,39 @@ }, { "session": { - "id": "jackson-the-dev", - "sourceId": "GGHN3U", - "title": "Jackson the Dev", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "issuance-endgame-stake-targeting", + "sourceId": "39HYEG", + "title": "Issuance Endgame: Stake Targeting", + "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like. \r\n\r\nWe argue that it should include an issuance policy that targets a range of staking ratios instead. The intention is to be secure enough but avoid overpaying for security and thereby enabling said negative externalities.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "none" + ], + "tags": [ + "ACD", + "Staking", + "Economics", + "ACD", + "Economics", + "Staking" + ], "language": "en", - "speakers": [], + "speakers": [ + "caspar-schwarz-schilling", + "ansgar-dietrichs" + ], "eventId": "devcon-7", - "slot_start": 1731664800000, - "slot_end": 1731668400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4" + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8" }, "vector": [ - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -442039,6 +442403,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -442410,6 +442775,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -442755,6 +443121,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -442848,6 +443215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -443005,6 +443373,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -443282,9 +443651,10 @@ 2, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -443300,34 +443670,25 @@ }, { "session": { - "id": "json-rpc-enhancement-in-geth", - "sourceId": "7KZLFF", - "title": "JSON-RPC Enhancement in Geth", - "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "jackson-the-dev", + "sourceId": "GGHN3U", + "title": "Jackson the Dev", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "execution client", - "json-rpc" - ], - "tags": [ - "Architecture", - "Frameworks", - "User Experience" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "jsvisa" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731469500000, - "slot_end": 1731470400000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc" + "slot_start": 1731664800000, + "slot_end": 1731668400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4" }, "vector": [ 0, @@ -443339,13 +443700,17 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -443759,7 +444124,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -444084,7 +444448,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -444130,7 +444493,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -444173,7 +444535,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -444630,9 +444991,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -444652,36 +445014,34 @@ }, { "session": { - "id": "keynote-glass-houses-and-tornados", - "sourceId": "K9A8EG", - "title": "Keynote: Glass Houses and Tornados", - "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.", - "track": "Cypherpunk & Privacy", - "type": "Talk", + "id": "json-rpc-enhancement-in-geth", + "sourceId": "7KZLFF", + "title": "JSON-RPC Enhancement in Geth", + "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Lobby", - "featured": true, + "audience": "Engineering", + "featured": false, "doNotRecord": false, "keywords": [ - "Legal", - "Government", - "Regulation" + "execution client", + "json-rpc" ], "tags": [ - "Governance", - "Mixers", - "Open Source Software", - "Privacy" + "Architecture", + "Frameworks", + "User Experience" ], "language": "en", "speakers": [ - "peter-van-valkenburgh" + "jsvisa" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731649800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c" + "slot_start": 1731469500000, + "slot_end": 1731470400000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc" }, "vector": [ 0, @@ -444689,8 +445049,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -444701,6 +445059,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -445440,6 +445799,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -445484,6 +445845,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -445518,9 +445880,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -445528,6 +445888,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -445539,7 +445900,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -445818,7 +446178,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -445984,11 +446343,13 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, + 2, 0, 0, 0, @@ -446001,44 +446362,41 @@ 0, 0, 0, - 2 + 0 ] }, { "session": { - "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation", - "sourceId": "MDHXHK", - "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation", - "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.", + "id": "keynote-glass-houses-and-tornados", + "sourceId": "K9A8EG", + "title": "Keynote: Glass Houses and Tornados", + "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.", "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Lobby", "featured": true, "doNotRecord": false, "keywords": [ - "Linux Foundation", - "Open Development" + "Legal", + "Government", + "Regulation" ], "tags": [ + "Governance", + "Mixers", "Open Source Software", - "FOSS", - "Best Practices", - "development", - "open", - "Best Practices", - "FOSS", - "Open Source Software" + "Privacy" ], "language": "en", "speakers": [ - "hart-montgomery" + "peter-van-valkenburgh" ], "eventId": "devcon-7", - "slot_start": 1731649800000, - "slot_end": 1731651600000, + "slot_start": 1731648600000, + "slot_end": 1731649800000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8" + "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c" }, "vector": [ 0, @@ -446131,7 +446489,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -446472,6 +446829,18 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -446810,7 +447179,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -446866,6 +447234,16 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -447113,32 +447491,12 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -447341,13 +447699,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -447358,39 +447716,45 @@ 0, 0, 0, - 0 + 0, + 2 ] }, { "session": { - "id": "keynote-infinite-diversity-in-infinite-combinations", - "sourceId": "3MNMHA", - "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations", - "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.", - "track": "Real World Ethereum", + "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation", + "sourceId": "MDHXHK", + "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation", + "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.", + "track": "Cypherpunk & Privacy", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Developer", "featured": true, "doNotRecord": false, "keywords": [ - "Plurality" + "Linux Foundation", + "Open Development" ], "tags": [ - "Decentralization", - "Governance", - "Political systems" + "Open Source Software", + "FOSS", + "Best Practices", + "development", + "open", + "Best Practices", + "FOSS", + "Open Source Software" ], "language": "en", "speakers": [ - "audrey-tang" + "hart-montgomery" ], "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731391200000, + "slot_start": 1731649800000, + "slot_end": 1731651600000, "slot_roomId": "main-stage", - "sources_youtubeId": "n3R4ze2hesk", - "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60" + "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8" }, "vector": [ 0, @@ -447398,7 +447762,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -447484,6 +447847,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -447824,9 +448188,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -448166,6 +448527,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -448227,7 +448589,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -448237,7 +448598,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -448470,6 +448830,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -448531,6 +448893,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -448701,7 +449064,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -448710,39 +449072,43 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "keynote-lessons-learned-from-tor", - "sourceId": "ZHU7UQ", - "title": "Keynote: Lessons learned from Tor", - "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.", - "track": "Cypherpunk & Privacy", + "id": "keynote-infinite-diversity-in-infinite-combinations", + "sourceId": "3MNMHA", + "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations", + "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.", + "track": "Real World Ethereum", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Community", "featured": true, "doNotRecord": false, "keywords": [ - "Human", - "rights" + "Plurality" ], "tags": [ - "Anonymity", - "Privacy", - "Sustainability" + "Decentralization", + "Governance", + "Political systems" ], "language": "en", "speakers": [ - "roger-dingledine" + "audrey-tang" ], "eventId": "devcon-7", - "slot_start": 1731651600000, - "slot_end": 1731654000000, + "slot_start": 1731389400000, + "slot_end": 1731391200000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E" + "sources_youtubeId": "n3R4ze2hesk", + "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae", + "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60" }, "vector": [ 0, @@ -448750,9 +449116,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -449509,7 +449874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -449582,13 +449946,17 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -449600,7 +449968,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -449833,7 +450200,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -450045,7 +450411,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -450056,6 +450421,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -450067,35 +450434,34 @@ }, { "session": { - "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy", - "sourceId": "NKMLNG", - "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy", - "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu", + "id": "keynote-lessons-learned-from-tor", + "sourceId": "ZHU7UQ", + "title": "Keynote: Lessons learned from Tor", + "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.", "track": "Cypherpunk & Privacy", "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", + "expertise": "Intermediate", + "audience": "Engineering", "featured": true, "doNotRecord": false, "keywords": [ - "cypherpunk" + "Human", + "rights" ], "tags": [ - "Zk Rollups", - "Privacy", - "cypherpunk", + "Anonymity", "Privacy", - "Zk Rollups" + "Sustainability" ], "language": "en", "speakers": [ - "zac-williamson" + "roger-dingledine" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, + "slot_start": 1731651600000, + "slot_end": 1731654000000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw" + "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E" }, "vector": [ 0, @@ -450530,7 +450896,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -450864,6 +451229,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -450905,7 +451271,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -450953,9 +451318,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -451188,6 +451553,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -451218,7 +451584,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -451415,40 +451780,42 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "keynote-making-sense-of-stablecoins", - "sourceId": "TDHR79", - "title": "Keynote: Making Sense of Stablecoins", - "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?", - "track": "Real World Ethereum", + "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy", + "sourceId": "NKMLNG", + "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy", + "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu", + "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Developer", "featured": true, "doNotRecord": false, "keywords": [ - "Stablecoins", - "Layer 2", - "RWA" + "cypherpunk" ], "tags": [ - "Ethereum for Good", - "Payment", - "RWA" + "Zk Rollups", + "Privacy", + "cypherpunk", + "Privacy", + "Zk Rollups" ], "language": "en", "speakers": [ - "liam-horne" + "zac-williamson" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, + "slot_start": 1731556800000, + "slot_end": 1731558600000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI" + "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw" }, "vector": [ 0, @@ -451456,7 +451823,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -451777,7 +452143,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -451886,6 +452251,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -452260,6 +452626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -452307,6 +452674,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -452315,7 +452683,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -452330,7 +452697,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -452343,7 +452709,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -452574,6 +452939,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -452753,9 +453119,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -452768,54 +453134,51 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem", - "sourceId": "VQKXUH", - "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem", - "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.", - "track": "Developer Experience", + "id": "keynote-making-sense-of-stablecoins", + "sourceId": "TDHR79", + "title": "Keynote: Making Sense of Stablecoins", + "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?", + "track": "Real World Ethereum", "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", + "expertise": "Beginner", + "audience": "Product", "featured": true, "doNotRecord": false, "keywords": [ - "ecosystem" + "Stablecoins", + "Layer 2", + "RWA" ], "tags": [ - "Developer Infrastructure", - "DevEx", - "Tooling" + "Ethereum for Good", + "Payment", + "RWA" ], "language": "en", "speakers": [ - "patricio-palladino" + "liam-horne" ], "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731569400000, + "slot_start": 1731470400000, + "slot_end": 1731472200000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE" + "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI" }, "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -453135,6 +453498,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -453184,7 +453548,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -453561,7 +453924,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -453570,7 +453932,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -453594,7 +453955,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -453677,6 +454037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -453691,6 +454052,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -453703,6 +454065,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -454102,7 +454470,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -454114,6 +454481,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -454124,47 +454495,39 @@ }, { "session": { - "id": "keynote-programmable-cryptography-and-ethereum", - "sourceId": "MQ8T8Z", - "title": "Keynote: Programmable Cryptography and Ethereum", - "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.", - "track": "Applied Cryptography", + "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem", + "sourceId": "VQKXUH", + "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem", + "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.", + "track": "Developer Experience", "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Developer", "featured": true, "doNotRecord": false, - "tags": [ - "Cryptography", - "Use cases of cryptography" - ], "keywords": [ - "Programmable", - "Cryptography" + "ecosystem" + ], + "tags": [ + "Developer Infrastructure", + "DevEx", + "Tooling" ], - "duration": 1517, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "UWPg_AmWtlw", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt", - "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.", + "speakers": [ + "patricio-palladino" + ], "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731400200000, + "slot_start": 1731567600000, + "slot_end": 1731569400000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4", - "resources_slides": null, - "speakers": [ - "gubsheep" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -454172,7 +454535,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -454349,7 +454711,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -454545,6 +454906,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -454913,7 +455275,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -454923,15 +455284,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -454955,6 +455317,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -455462,13 +455825,13 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -455484,41 +455847,42 @@ }, { "session": { - "id": "keynote-the-next-10-years-of-web3-in-africa", - "sourceId": "GSNQLC", - "title": "Keynote: The next 10 years of Web3 in Africa", - "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?", - "track": "Real World Ethereum", + "id": "keynote-programmable-cryptography-and-ethereum", + "sourceId": "MQ8T8Z", + "title": "Keynote: Programmable Cryptography and Ethereum", + "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", + "expertise": "Beginner", + "audience": "Engineering", "featured": true, "doNotRecord": false, - "keywords": [ - "Africa", - "Mass adoption", - "" - ], "tags": [ - "Ethereum Roadmap", - "Use Cases", - "macro/micro economics", - "adoption", - "africa", - "mass", - "Ethereum Roadmap", - "macro/micro economics", - "Use Cases" + "Cryptography", + "Use cases of cryptography" ], - "language": "en", - "speakers": [ - "yoseph-ayele" + "keywords": [ + "Programmable", + "Cryptography" ], + "duration": 1517, + "language": "en", + "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9", + "sources_youtubeId": "UWPg_AmWtlw", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt", + "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.", "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8" + "slot_start": 1731398400000, + "slot_end": 1731400200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4", + "resources_slides": null, + "speakers": [ + "gubsheep" + ] }, "vector": [ 0, @@ -455527,11 +455891,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -455708,6 +456072,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -455906,7 +456271,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -456273,6 +456637,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -456287,6 +456652,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -456338,7 +456704,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456417,8 +456782,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -456472,7 +456835,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456496,7 +456858,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456657,7 +457018,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456821,7 +457181,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456831,6 +457190,12 @@ 0, 2, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -456843,39 +457208,49 @@ }, { "session": { - "id": "keynote-the-real-state-of-l2s", - "sourceId": "HCXUU8", - "title": "Keynote: The REAL state of L2s", - "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.", - "track": "Layer 2", + "id": "keynote-the-next-10-years-of-web3-in-africa", + "sourceId": "GSNQLC", + "title": "Keynote: The next 10 years of Web3 in Africa", + "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?", + "track": "Real World Ethereum", "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Product", "featured": true, "doNotRecord": false, - "keywords": [ - "L2Risks", - "Myths&Reality" - ], "tags": [ - "Architecture", - "Layer 2s", - "Best Practices", - "myths", - "reality", - "Architecture", - "Best Practices", - "Layer 2s" + "Ethereum Roadmap", + "Use Cases", + "macro/micro economics", + "adoption", + "africa", + "mass", + "Ethereum Roadmap", + "macro/micro economics", + "Use Cases" ], - "language": "en", - "speakers": [ - "bartek-kiepuszewski" + "keywords": [ + "Africa", + "Mass adoption" ], + "duration": 1531, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "NtkNYNvuu6w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f64b3a168eb53542528d.vtt", + "transcript_text": " Leonardo Silva Reviewer:\" Elisabeth Buffard Hello everyone. Good to see you all today. I want to start off by asking who is here from the continent of Africa. Can you please raise your hand? Can you guys please stand up? Can you guys please stand up? Let's give this guy a big round of applause because like many of our folks have gone through crazy lengths to get themselves here with visas and everything. And this is the DEF CON that has the largest African builder concentration in one place. And my talk today is around what can we expect over the next 10 years in terms of crypto innovation and is very much inspired by a lot of what I've learned from all these folks and many more of what are the things that have been built today and what can we expect coming up. So two years ago at DEF CON, we established the fact that it's actually the crypto ecosystem that needs Africa to reach its full potential of reaching mass adoption and utility-driven building to scale it to billions of people. And we covered the fact that we are the most populous part of the world and we're growing really fast. That is going to be where all the young people in the world are going to be based at even today we have about 600 million Africans who are the end under the age of 14 that's out of 1.5 billion people and we also discussed around the technology rails that exist that how allowed us to basically skip generations of innovations such as mobile phones skipping landlines or mobile money where that has close to trillion dollars worth of transactions a year and we're jumping traditional banking with crypto. Two years ago when we discussed a lot of this, what was the reality is that mostly many of us were doing crypto to fiat transactions doing payments savings and storing resources or investing using predominantly centralized exchanges and a lot of centralized exchanges are actually not made to be banks they're trading platforms but we kind of figured a way to do that by having various liquidity providers like people like you and I providing liquidity on peer-to-peer their trading platforms. But we kind of figured a way to do that by having various liquidity providers like people like you and I, providing liquidity on peer-to-peer exchanges to drive a lot of the value for normal people to access traditional forms of banking that we need. So where are we today, two years from then? Well, the one reality is that in the traditional world we're still in the same place, that we are communicating value over walls, that the internet, as amazing as it's been at connecting us and letting communication flow, communication of value, which is through monetary systems, are actually very much gated. The internet continues to be very gated. The same way back in the days you would have an operator basically connecting two calls by manually calling the other side and seeing can we trust the other operator. That's the same process that we have today. So we are still working through walls in the traditional system. The other aspect of where we still are today is that a huge part of our economy is happening in the informal sector. That includes our GDP, our prominent GDP is backed by micro enterprises. A huge part of our employment is in the informal economy. A huge part of our GDP is also drive by the informal economy. A huge part of our GDP is also drived by the informal economy and also a lot of our money movement happens outside of the banking system. This is a very important context for us to understand why crypto is thriving so much on the continent. Another big also lens is that we have a systemic US dollar problem. Some of these numbers are a bit outdated but we're importing more than what we're exporting we're taking a lot of debt a lot of african countries debt has doubled in the last 10 years and we're paying that debt plus interest in dollars and we're trading with each other as neighbors using dollars and when our currencies fluctuate so much, then we move our money to dollars. So that creates a demand supply. And on the supply pressure, we have a lot of exports, remittance, people sending money. There's a thing called BRIC. Some of you guys might know about it. Around some countries deciding to settle outside of the dollar system, which is creating a bit less pressure on the dollar. And there's a lot of aid and loans that come in dollars. So what is the consequence of this? Is that basically the US dollars are being rationed by the central banks. The demand for dollars is higher than what they have there. So what you end up having is the bifurcation of the bank rate and the black market rate, or how I call it, the actual market rate um and in worse economies you see that being very large in well-managed economies it's very small but we're living in in parallel systems and also that makes the dollar a commodity so people do unnatural things in order to access dollars because the upside on trading the dollar is higher than the trade on the commodity itself, which creates very weird dysfunctions in our system. And some countries have also created rules of who can own dollars and how much you can transfer it. Until very recently, the Ethiopian government actually made it illegal, meaning you can go to prison for it, for holding more than $500 with you at any given point. Many of my friends' and family's houses were raided, just people looking for dollars. And that's because the central banks don't have enough dollars. And what that means, we borrow more money and then just rinse and repeat. So we have a systemic dollar problem. And so you look at that and say, okay, well, what is crypto doing? Well, fundamentally, what crypto has provided us is basically a digital version of the dollar, US dollar stable coins, that allow for large-scale liquidity coordination mechanism in the informal economy, where a lot of dollars have been circulating physically or through various networks like the Hawala networks that call each other and basically move numbers around. What has that allowed us is basically for early stage startups to be able to aggregate more liquidity than what a bank can in a very short period of time and then settle that payment in a much shorter period of time. And this has been a fundamental value proposition of crypto. So as a result of that, crypto has been thriving, it's been growing. Even in the bear market, crypto transactions have been growing on the continent. Chainalysis says we've had $125 billion worth of transactions last year. When I talk to the analysts and the builders, that's just the tip of the iceberg. There's much more dollars that's been transacted behind that. Nigeria of course is the second most popular place for crypto. And Nigeria, Ethiopia, Kenya, we search crypto online because it is solving fundamental problems for us. But this is not just centralized exchanges. This is happening in other rails that have been built. So actually, some of the builders here in this room have built some of these stacks. These are from the builders in Magma, from wallet infrastructure. So actually making like SDK wallets that you can embed into your fintech application or your crypto application. So you can use crypto and fiat. Aggregating liquidity on-chain and off- off chain which is actually not very easy to do and and simplify the on and off run process through that different types of wallets that are being created and all types of payments from b2b b2c b2b b2c serving like small businesses medium, medium-sized businesses, oil and gas companies, and even banks and payment service providers who are now using these startups to facilitate international payments. And people even issuing debit cards on top of your digital wallet in order to be able to pay online without having any limitations, because some of our banks say, I'm so sorry, you can only pay $10 a month. Well, if you have some resource, you want to buy a book from Amazon, how can you buy it with $10? Amazon is more expensive than that. So you're actually using crypto projects in order to do that. And so some of these projects are way advanced than where I see a lot of on and off ramps. And so, bluntly speaking, if DEF CON was held in one of the countries that were mentioned in Africa, the DEF CON organizing team can pay all their bills using crypto. All of us would basically be using our crypto to make payments with fiat without even needing a fiat wallet paying directly just using the applications that have been built today so there's been a lot of work that has happened in terms of making the user experience a lot easier and if you're curious about it just talk to many of the builders who are in this room so with that in mind what can we expect in the next 10 years what are some of the innovations that we can expect to have? Well, fundamentally, I think the most interesting part of crypto to me is bringing whole economies and powering them by decentralized systems. Part of that is basically changing the foundations of our existing economy, and part of it is like opening up new economic activities that we did not know existed before um and this is where i think ethereum comes in because that's the most robust and the most resilient decentralized system that we have right now so it's it's a beautiful merge here and when we think about rewriting a lot of the foundations of our economies we've got to think about both hyper globalizationglobalization and hyper-localization. We talked a lot about US dollar stablecoins, right? So the answer is not, let's dollarize the entire African economy. Everyone uses dollars, dollars for everyone. That's not the answer. I don't think that helps us and it doesn't help the global economy. So we've got to also think very locally. And one idea I'd love to dive deeper on is this idea of actually local currency stable coins. At the moment, when we think about stable coins, it's kind of synonymous with US dollar stable coins. How about actually having our Kenyan, Nigerian shillings, Nigerian naira, Ethiopian burr, a lot of our local currencies having a digital version of them on-chain. What does that allow? Well, on-chain forex. That makes it a lot more efficient. We'll double-click on that. Cheaper local payments. In a crazy way today, with blobs, it is cheaper to run transactions on a layer 2 at least 5 to 10 times than it is on mobile money or banking, which is quite crazy. Well, that doesn't mean blobs will scale infinitely, but it's just an interesting data point of what we can even do today. And the last part of the value here that we can think of at this stage is that it gives us programmable money, and that opens up a whole lot of opportunities and innovations that can happen. I really want to double click on the on-chain forex. Well today Kenya and Tanzania are neighboring countries right next to each other. We even speak similar languages and both our currencies are called shillings. But in order to make a payment from Kenya to Tanzania you actually have to convert it to the dollar. Dollar has to go through the trade system. It has to flow through London or New York or somewhere. It can take a few days, and depending on the volume, it can take even weeks. It's a very long process and long system. It doesn't make sense that we're having to do this as neighbors, right? With local stablecoins, you could potentially move from the Canadian shilling stablecoin to a Tanzanian shilling stable coin, both denominated in value against the dollar, but not actually touching the dollar. So this helps us move the US dollar from just being a medium of exchange to being a unit of account, which is a very interesting use case for it. So one way that can work is building a pair of liquidity where an importer is putting money into the pool from the Kenyan side and an exporter is pulling money out of it. And the person does the exact same thing on the Tanzanian front. And because every trade does not fully balance, you use dollars to basically rebalance the pool by adding local currency on the other side. This is just one model. I am sure we can come up with way more complex and more interesting models to structure this. But bringing forex on chain is one of the most interesting problems for us to solve using local stable coins. Now, when we think about that, we can think in a few million dollar value, or we can think about half economies. And I think the most important thing that we keep missing in the space when we look at the full potential of crypto is that we're not always looking at how can half an economy run on what we're building, and what needs to be true for us to get there. And the reason why I'm saying that is because, you know, many of you know M-Pesa, right? M-Pesa is one of the best success stories that has come out of Kenya. Half the Kenyan economy runs on M-Pesa. What M-Pesa is, is just a private ledger. It's a spreadsheet where they put some fiat in the bank, and the numbers move from different account names and at the end of the day it's basically settled at the bank layer that's somehow a version of what we're talking about but what we're talking about is putting that on chain and a much more open transparent system right for us to get to that level of scale at a much faster period we've got to think about from different principles and and one lens that I can think of is using government bonds to back our local stable coins. You convert the local bond into a real world asset that can either be fully collateralized through a CDP or a better model that we can come up with. And by the way, if you do, I'd love to chat with you. And basically use that to distribute local currency through existing and new rails around. The forex on-chain is one of the lowest-hanging fruit examples of where we can go, but we can bring so many other values to that. And in the future, it doesn't just need to be government bonds to do this. We can bring other types of assets assets like local land, productive land or protected land or gold and silver and precious metals. We're generating so much of that from Africa at the moment. Or we can do other types of commodities. This is such an open book in terms of what we back our local currencies with. Another pillar after local stablecoins that I love to chat about is simple finance as a stack. Now, here in the Ethereum world, we talk about decentralization a lot. Well, for us on the continent, decentralization is actually a very practical solution to a very practical problem. We have a lot of banking rails to build for hundreds of millions of people, and many of them have not been born yet. To do that, trying to build that in a monolithic way as a centralized company, as one piece, like Alipay or WeChat or Grab for 54 jurisdictions, and scale that in a very short period of time is almost impossible to execute. So the best way for us to do that that in a very short period of time, is almost impossible to execute. So the best way for us to do that, in my view, is just to build a connected web of tools. Different pieces of the Lego that form a financial stack that come together, that offer users a better experience and better options, right? I think building this in a much more decentralized way, to me, is the only way we can get to the level of scale that we need to achieve. So for us, it's actually a very practical solution, a practical way of getting there. And we can build interoperable monies with network effects. Remember the walls, the operator? We can just bypass that and keep moving value across different populations and people in that way. Create cash apps with simple user experience powered by crypto, but we don't even have to know that it's crypto. Today we have startups that are doing that, but we can scale that to infinity. And on the hyper-localization lens, there are many ways we can build around existing trust structures. Across many African countries, we have basically cooperatives and little communities of people. Some of us call them table banking, some of us call them chamas, where basically people pull money together to save and lend to each other. There's a strong trust infrastructure that exists to enable things like that. We don't have to reinvent trust from scratch. We can leverage those existing trust structures to build very resilient, hyper-local economies. And I think that should be part of our roadmap. And beyond, you know, so ultimately, it's just two people or two companies or two agents having normal financial transactions, right? No complexity, not much. We're not talking about crypto at the front end. This is all enabling that. Other areas of innovation that we can think about is like around credentialing, identity, reputation, credit scoring, bringing things that don't exist on chain to create trust on chain are some of the more interesting areas for us to experiment on. We don't have time to dive deep into many of these, and there's a lot more than other areas of innovation that we can build in the next 10 years, but talk to the builders around the table. And the other areas bringing assets on chain, such as real estate. We talked about bonds earlier, but different types of commodities, energy, power generating structures that we need to fund and actually revenue generating. We can experiment with so many of these that actually powers the fundamentals of our economies. So with all these ideas and directions that we can go, you might be wondering, how do I help? How do I connect? How do I participate in this? Well, the first is it's an invitation. It's actually an invitation because there's a lot of building happening on the continent, whether we have a lot of builders coming to DEF CON or not. So it's an invitation for you all from infrastructure, from research, from different ecosystems and chains, from capital allocation, from mentorship and support, from actually working with some of the smartest people on the planet. There are many ways you can plug it into the movement that is happening in Africa. And of course, why not bring DEF CON to Africa in two years' time? Who's down for something like that here? Right? Well, yeah, I think that would be super cool, and you guys will have a blast joining DEF CON there. But it's actually not about having another big event on the continent. It's actually, it gives you a much deeper context to go and see this in practice. It is very, very hard to explain how broken the world gardens are until you actually go and experience it in person. Or it's very hard for me to explain to you like what seamless user experience for crypto looks like without actually going and experiencing and making a whole lot of payments and living your life using your crypto wallet without touching physical bills, right? So it's an invitation for you to actually be part of the movement and work that we have. And lastly, because all the Ethereum events that have happened around the world have happened in places where it's just very hard to get visas, right. So to get 177 folks here, man, that was like a lot of work and it's been a lot of collective effort. And there are hundreds and thousands more that you would absolutely enjoy connecting with and learning with and learning from. And so you're invited home. Welcome, guys. All right. That was an awesome presentation, you guys. We have a Q&A session. So anyone want to put a question, that's the QR right there. Just scan it and put a question there. We have a lot for you, brother. Yes. Let's take a look at which one you want to answer first. We can talk about the non-financial use cases. We can talk about the non-financial use cases. We talked about them later on. Yeah, this talk focused a lot on finance because it's just a lot to unpack. And each topic that we talked around, credentialing, around bringing assets on-chain, and credit scoring, and gaming, and communication, there's a lot to unpack there. I will actually invite you guys to talk to some of our builders here to understand a lot of the nuances. But at the moment, 500 million Africans don't have any form of legal ID. And the best that some of our countries are doing is basically having a data center in one location or two locations and putting the entire population's data there. It's like a honeypot of sovereign data. That's not the most secure way to do it, in my opinion. the entire population's data there. It's like a honeypot of sovereign data, right? That's not the most secure way to do it, in my opinion. So I think there's a lot of ways we can innovate around that. KYC is one that really came up, like transferable KYC across multiple tools. So the list goes on. So the invitation is to actually talk to the builders in the room. Any questions you want to answer? We have a lot more here. All right. What do you see Africa becoming? What do you see Africa becoming a well-coordinated roadmap? I want to talk about regulation. All right, let's go. Because that continues to be a hot topic. And it's really important to us because many of our innovations are interfacing the traditional world with the crypto world because that that door needs to be very fluid it needs to allow money to keep moving back and forth for a long period of time and until we bring it on chain um and i think that's a that's a very important problem so i talked to a bunch of regulators many of the builders here talk to many regulators there's there's curiosity, there's some fear because crypto can be a path for capital flight. A lot of value to live in a short period of time. And that's an actual risk. And some of them don't even understand the fundamentals of this technology. So what we end up having is some countries like South Africa saying, crypto is legal. It's a commodity. We will allow it and so we have a lot of builders working there some countries creating environments for experimentation like sandboxes and actually this is a bit of a controversial view but I think creating some sort of tax revenue from crypto transactions for governments is a potentially positive thing if it's done well, because it moves this category from a risk basis to an income generating category. And bringing local stable coins on chain is, I think, one of the biggest value props for governments, because what it does is it creates a much more efficient capital markets for dollars and bonds it brings dollars in and helps reduce the dollar pressure for local trade that can happen so they have an incentive to see something like that but there's a lot of people here doing the hard work of actually informing regulators and we keep building like we keep building even with gray area we keep building like the show doesn't stop. And I think that's something some of us in, like, the Western world find it hard to kind of navigate around, is because, like, even when Nigeria makes crypto illegal, like, we still have close to 15% of the country's GDP, like, proportion transactions happening in crypto, right? So, yeah, it makes you kind of wonder what some of those kind of guidelines can actually have an effect. I think we have about one or two questions more. Let's see what we want to answer. Am I hiring? Are you hiring? I mean, I don't know, guys. We can jam outside after this and recruit more folks to help answer the question. But yeah, I guess what needs to happen before a DEF CON happens there is there's a lot we've got to do on the continent. We have many communities doing real work. They need a lot of support and engagement. So I think that will bring a lot of value. We need to have more hackathons and builders. But, like, I think our builder community, like, the startups that we have there are, from a user experience perspective, in my opinion, are, like, way ahead from what we keep talking about around usability making crypto usable for daily life like whenever I'm in many African countries like I don't use my card, I don't use cash I'm just like paying all types of bills using my crypto account and I think that's super cool and that's amazing so like even the bill of community alone is enough to host you all. All right. Give a round of applause for the speaker. Thank you.", "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0" + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8", + "resources_slides": null, + "speakers": [ + "yoseph-ayele" + ] }, "vector": [ 0, @@ -456884,7 +457259,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -457264,6 +457638,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -457312,7 +457687,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -457647,7 +458021,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -457678,11 +458051,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -457700,6 +458071,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -457778,6 +458150,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -457812,6 +458186,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -457832,6 +458207,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -457862,7 +458238,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -458178,8 +458553,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -458195,38 +458570,45 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "keynote-the-universal-cryptographic-adapter", - "sourceId": "R9X9ZG", - "title": "Keynote: The Universal Cryptographic Adapter", - "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.", - "track": "Applied Cryptography", + "id": "keynote-the-real-state-of-l2s", + "sourceId": "HCXUU8", + "title": "Keynote: The REAL state of L2s", + "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.", + "track": "Layer 2", "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Community", "featured": true, "doNotRecord": false, "keywords": [ - "None" + "L2Risks", + "Myths&Reality" ], "tags": [ - "Not financial", - "Permissionless", - "ZKP" + "Architecture", + "Layer 2s", + "Best Practices", + "myths", + "reality", + "Architecture", + "Best Practices", + "Layer 2s" ], "language": "en", "speakers": [ - "justin-glibert" + "bartek-kiepuszewski" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg" + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0" }, "vector": [ 0, @@ -458236,10 +458618,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -458415,7 +458797,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -458664,6 +459045,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -458999,6 +459381,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459029,9 +459412,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -459042,7 +459427,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459159,8 +459543,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -459205,7 +459587,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459216,6 +459597,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459367,6 +459749,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459529,16 +459912,16 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -459551,60 +459934,46 @@ }, { "session": { - "id": "keynote-title-redacted", - "sourceId": "8GH8TR", - "title": "Keynote: [title redacted]", - "description": "[description redacted]", - "track": "Core Protocol", + "id": "keynote-the-universal-cryptographic-adapter", + "sourceId": "R9X9ZG", + "title": "Keynote: The Universal Cryptographic Adapter", + "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Expert", + "audience": "Engineering", "featured": true, "doNotRecord": false, - "tags": [ - "Consensus", - "Ethereum Roadmap", - "cryptoeconomy", - "Consensus", - "Core Protocol", - "Ethereum Roadmap" - ], "keywords": [ - "beacon chain", - "research", - "cryptoeconomics" + "None" + ], + "tags": [ + "Not financial", + "Permissionless", + "ZKP" ], - "duration": 1553, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "Gjuenkv1zrw", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU", - "resources_slides": null, "speakers": [ - "justin-drake" - ] + "justin-glibert" + ], + "eventId": "devcon-7", + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -459780,6 +460149,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -460029,7 +460399,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -460337,7 +460706,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -460351,7 +460719,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -460410,6 +460777,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -460525,6 +460894,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460569,9 +460939,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -460732,7 +461103,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -460894,16 +461264,16 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -460916,50 +461286,57 @@ }, { "session": { - "id": "keynote-unifying-ethereum-through-intents-and-erc-7683", - "sourceId": "WHYZCD", - "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683", - "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.", - "track": "Layer 2", + "id": "keynote-title-redacted", + "sourceId": "8GH8TR", + "title": "Keynote: [title redacted]", + "description": "[description redacted]", + "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Community", "featured": true, "doNotRecord": false, - "keywords": [ - "ERC-7683", - "Interoperability" - ], "tags": [ - "Cross-L2", - "UI/UX", - "Intents", - "interoperability", - "erc-7683", - "Cross-L2", - "Intents", - "UI/UX" + "Consensus", + "Ethereum Roadmap", + "cryptoeconomy", + "Consensus", + "Core Protocol", + "Ethereum Roadmap" ], - "language": "en", - "speakers": [ - "hart-lambur" + "keywords": [ + "beacon chain", + "research", + "cryptoeconomics" ], + "duration": 1553, + "language": "en", + "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e", + "sources_youtubeId": "Plvy7fgFCm4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, + "slot_start": 1731405600000, + "slot_end": 1731407400000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY" + "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU", + "resources_slides": null, + "speakers": [ + "justin-drake" + ] }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -461696,6 +462073,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -461709,6 +462087,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -461744,11 +462123,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -461862,7 +462239,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -461886,10 +462262,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -462081,7 +462457,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462093,6 +462468,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -462259,8 +462638,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -462273,31 +462652,39 @@ }, { "session": { - "id": "keynote-world-politics-world-building", - "sourceId": "ERQKUX", - "title": "Keynote: World Politics, World Building", - "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode", - "track": "Real World Ethereum", + "id": "keynote-unifying-ethereum-through-intents-and-erc-7683", + "sourceId": "WHYZCD", + "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683", + "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", - "audience": "Academic", + "expertise": "Intermediate", + "audience": "Product", "featured": true, "doNotRecord": false, "keywords": [ - "World Building", - "Technology", - "Geopolitics" + "ERC-7683", + "Interoperability" + ], + "tags": [ + "Cross-L2", + "UI/UX", + "Intents", + "interoperability", + "erc-7683", + "Cross-L2", + "Intents", + "UI/UX" ], - "tags": [], "language": "en", "speakers": [ - "bruno-macaes" + "hart-lambur" ], "eventId": "devcon-7", - "slot_start": 1731652200000, - "slot_end": 1731654000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q" + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY" }, "vector": [ 0, @@ -462306,9 +462693,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -463095,9 +463481,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -463211,6 +463599,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463239,6 +463628,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463428,6 +463818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463597,23 +463988,20 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -463622,39 +464010,31 @@ }, { "session": { - "id": "kickstarting-impact-funding-with-hypercerts", - "sourceId": "VGZ7PP", - "title": "Kickstarting impact funding with hypercerts", - "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.", + "id": "keynote-world-politics-world-building", + "sourceId": "ERQKUX", + "title": "Keynote: World Politics, World Building", + "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode", "track": "Real World Ethereum", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, + "type": "Talk", + "expertise": "Beginner", + "audience": "Academic", + "featured": true, "doNotRecord": false, "keywords": [ - "Impact", - "Funding" - ], - "tags": [ - "DevEx", - "RPGF", - "Best Practices", - "funding", - "Best Practices", - "DevEx", - "RPGF" + "World Building", + "Technology", + "Geopolitics" ], + "tags": [], "language": "en", "speakers": [ - "holke-brammer", - "bitbeckers" + "bruno-macaes" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731582000000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I" + "slot_start": 1731652200000, + "slot_end": 1731654000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q" }, "vector": [ 0, @@ -464094,8 +464474,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -464425,8 +464803,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -464661,7 +465037,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -464708,7 +465083,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -464957,7 +465331,12 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -464972,6 +465351,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0 @@ -464979,25 +465360,39 @@ }, { "session": { - "id": "ktv-attestation-winners", - "sourceId": "MP9UQV", - "title": "KTV Attestation Winners", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "kickstarting-impact-funding-with-hypercerts", + "sourceId": "VGZ7PP", + "title": "Kickstarting impact funding with hypercerts", + "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.", + "track": "Real World Ethereum", + "type": "Workshop", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Impact", + "Funding" + ], + "tags": [ + "DevEx", + "RPGF", + "Best Practices", + "funding", + "Best Practices", + "DevEx", + "RPGF" + ], "language": "en", - "speakers": [], + "speakers": [ + "holke-brammer", + "bitbeckers" + ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o" + "slot_start": 1731576600000, + "slot_end": 1731582000000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I" }, "vector": [ 0, @@ -465006,9 +465401,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -465441,6 +465833,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -465770,6 +466164,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -466005,6 +466401,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -466051,9 +466448,7 @@ 0, 0, 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -466304,6 +466699,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -466322,9 +466718,9 @@ }, { "session": { - "id": "ktv-winners", - "sourceId": "UYQFMA", - "title": "KTV Winners", + "id": "ktv-attestation-winners", + "sourceId": "MP9UQV", + "title": "KTV Attestation Winners", "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", "track": "Entertainment", "type": "Music", @@ -466337,10 +466733,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731501000000, - "slot_end": 1731501900000, + "slot_start": 1731486600000, + "slot_end": 1731488400000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y" + "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o" }, "vector": [ 0, @@ -467644,6 +468040,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -467665,45 +468062,25 @@ }, { "session": { - "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state", - "sourceId": "ERQ7N3", - "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State", - "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Beginner", + "id": "ktv-winners", + "sourceId": "UYQFMA", + "title": "KTV Winners", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "DevEx", - "Rollups" - ], - "keywords": [ - "RIP", - "L1SLOAD", - "Precompile" - ], - "duration": 5064, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "R9-QpN-hr6w", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731400200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E", - "resources_slides": null, - "speakers": [ - "peter-garamvolgyi", - "rh" - ] + "slot_start": 1731501000000, + "slot_end": 1731501900000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y" }, "vector": [ 0, @@ -467713,6 +468090,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -468146,8 +468525,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -468474,7 +468851,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -468486,7 +468862,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -468498,7 +468873,9 @@ 0, 0, 0, - 2, + 0, + 0, + 0, 0, 0, 0, @@ -469010,6 +469387,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -469028,39 +469406,45 @@ }, { "session": { - "id": "l1sload-precompile-read-l1-state-from-your-l2-contract", - "sourceId": "VRXWFH", - "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract", - "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.", + "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state", + "sourceId": "ERQ7N3", + "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State", + "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.", "track": "Layer 2", - "type": "Talk", + "type": "Workshop", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "RIPs", - "L1SLOAD", - "Precompile" - ], "tags": [ - "Cross-L2", "Developer Infrastructure", "DevEx", - "precompile", - "Cross-L2", - "Developer Infrastructure", - "DevEx" + "Rollups" ], - "language": "en", - "speakers": [ - "peter-garamvolgyi" + "keywords": [ + "RIP", + "L1SLOAD", + "Precompile" ], + "duration": 5064, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "R9-QpN-hr6w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs" + "slot_start": 1731394800000, + "slot_end": 1731400200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E", + "resources_slides": null, + "speakers": [ + "peter-garamvolgyi", + "rh" + ] }, "vector": [ 0, @@ -469504,6 +469888,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -469843,7 +470228,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -470001,7 +470386,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -470202,7 +470586,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -470385,38 +470770,39 @@ }, { "session": { - "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term", - "sourceId": "BF8EWR", - "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term", - "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.", - "track": "Coordination", + "id": "l1sload-precompile-read-l1-state-from-your-l2-contract", + "sourceId": "VRXWFH", + "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract", + "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.", + "track": "Layer 2", "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "structures", - "processes" + "RIPs", + "L1SLOAD", + "Precompile" ], "tags": [ - "Coordination", - "DAO", - "Governance", - "processes", - "Coordination", - "DAO", - "Governance" + "Cross-L2", + "Developer Infrastructure", + "DevEx", + "precompile", + "Cross-L2", + "Developer Infrastructure", + "DevEx" ], "language": "en", "speakers": [ - "krzysztof-urbanski" + "peter-garamvolgyi" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU" + "slot_start": 1731581400000, + "slot_end": 1731582600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs" }, "vector": [ 0, @@ -470426,10 +470812,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -470861,16 +471243,9 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -471199,6 +471574,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471222,6 +471598,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471253,12 +471630,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -471312,7 +471687,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471372,6 +471746,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471445,7 +471820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471571,6 +471945,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -471719,7 +472100,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471730,6 +472110,13 @@ 0, 2, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -471741,30 +472128,38 @@ }, { "session": { - "id": "l2-evm-common-core-a-path-beyond-evm-equivalence", - "sourceId": "9RJ3MA", - "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence", - "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.", - "track": "Layer 2", + "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term", + "sourceId": "BF8EWR", + "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term", + "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.", + "track": "Coordination", "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "structures", + "processes" + ], "tags": [ - "EVM-equivalent", - "Rollups" + "Coordination", + "DAO", + "Governance", + "processes", + "Coordination", + "DAO", + "Governance" ], "language": "en", "speakers": [ - "ansgar-dietrichs" + "krzysztof-urbanski" ], "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731582600000, + "slot_start": 1731638700000, + "slot_end": 1731640500000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk" + "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU" }, "vector": [ 0, @@ -471774,12 +472169,11 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -471823,7 +472217,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -472211,6 +472604,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -472547,7 +472941,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -472604,10 +472997,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -472661,6 +473056,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -472794,6 +473190,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -472829,7 +473226,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -473071,12 +473467,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -473089,37 +473485,30 @@ }, { "session": { - "id": "l2-interoperability-via-collaborative-snarks", - "sourceId": "JPGEPU", - "title": "L2 Interoperability via Collaborative SNARKs", - "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.", + "id": "l2-evm-common-core-a-path-beyond-evm-equivalence", + "sourceId": "9RJ3MA", + "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence", + "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.", "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Interoperability" - ], + "keywords": [], "tags": [ - "Fragmentation", - "Zk Rollups", - "Cryptography", - "interoperability", - "Cryptography", - "Fragmentation", - "Zk Rollups" + "EVM-equivalent", + "Rollups" ], "language": "en", "speakers": [ - "ben-fisch" + "ansgar-dietrichs" ], "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k" + "slot_start": 1731580800000, + "slot_end": 1731582600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk" }, "vector": [ 0, @@ -473178,6 +473567,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -473565,7 +473956,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -473873,7 +474263,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -473929,7 +474318,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -474186,6 +474574,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -474252,7 +474642,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -474422,8 +474811,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -474439,15 +474828,16 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "l2-specific-mev-mitigation-strategies", - "sourceId": "FFWJAV", - "title": "L2 Specific MEV Mitigation Strategies", - "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.", + "id": "l2-interoperability-via-collaborative-snarks", + "sourceId": "JPGEPU", + "title": "L2 Interoperability via Collaborative SNARKs", + "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.", "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", @@ -474455,26 +474845,26 @@ "featured": false, "doNotRecord": false, "keywords": [ - "DeFi" + "Interoperability" ], "tags": [ - "Layer 2s", - "Rollups", - "MEV", - "defi", - "Layer 2s", - "MEV", - "Rollups" + "Fragmentation", + "Zk Rollups", + "Cryptography", + "interoperability", + "Cryptography", + "Fragmentation", + "Zk Rollups" ], "language": "en", "speakers": [ - "joseph-poon" + "ben-fisch" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY" + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k" }, "vector": [ 0, @@ -474920,7 +475310,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -475217,7 +475606,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -475231,6 +475619,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -475257,9 +475647,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -475281,11 +475671,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -475408,7 +475798,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -475609,6 +475998,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -475799,54 +476190,47 @@ }, { "session": { - "id": "latency-advantage-in-cex-dex-arbitrage", - "sourceId": "RPMHLF", - "title": "Latency Advantage in CEX-DEX Arbitrage", - "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable", - "track": "Cryptoeconomics", - "type": "Lightning Talk", + "id": "l2-specific-mev-mitigation-strategies", + "sourceId": "FFWJAV", + "title": "L2 Specific MEV Mitigation Strategies", + "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.", + "track": "Layer 2", + "type": "Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Optimal", - "Stopping;", - "Dynamic", - "Programming;" + "DeFi" ], "tags": [ + "Layer 2s", "Rollups", - "Economics", "MEV", - "AMMs", - "programming", - "dynamic", - "AMMs", - "Economics", + "defi", + "Layer 2s", "MEV", "Rollups" ], "language": "en", "speakers": [ - "akaki-mamageishvili" + "joseph-poon" ], "eventId": "devcon-7", - "slot_start": 1731487200000, - "slot_end": 1731487800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI" + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY" }, "vector": [ 0, 0, - 6, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -476578,6 +476962,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -476611,7 +476997,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -476642,6 +477028,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -476659,7 +477047,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -476768,6 +477155,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -476978,8 +477366,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -477160,49 +477546,52 @@ }, { "session": { - "id": "launching-projects-out-of-the-global-majority", - "sourceId": "7VZ8WH", - "title": "Launching Projects out of the Global Majority", - "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.", - "track": "Real World Ethereum", + "id": "latency-advantage-in-cex-dex-arbitrage", + "sourceId": "RPMHLF", + "title": "Latency Advantage in CEX-DEX Arbitrage", + "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable", + "track": "Cryptoeconomics", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Business", + "audience": "Research", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Global" + "Optimal", + "Stopping;", + "Dynamic", + "Programming;" ], "tags": [ - "DAO", - "Sufficient decentralization", - "Best Practices", - "macro/micro economics", - "global", - "Best Practices", - "DAO", - "macro/micro economics", - "Sufficient decentralization" + "Rollups", + "Economics", + "MEV", + "AMMs", + "programming", + "dynamic", + "AMMs", + "Economics", + "MEV", + "Rollups" ], "language": "en", "speakers": [ - "james-waugh" + "akaki-mamageishvili" ], "eventId": "devcon-7", - "slot_start": 1731478800000, - "slot_end": 1731479400000, + "slot_start": 1731487200000, + "slot_end": 1731487800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc" + "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -477937,6 +478326,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -477964,18 +478354,19 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -478016,6 +478407,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -478034,7 +478426,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -478090,7 +478481,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -478146,7 +478536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -478338,6 +478727,8 @@ 0, 0, 2, + 2, + 0, 0, 0, 0, @@ -478500,9 +478891,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -478517,47 +478908,48 @@ }, { "session": { - "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto", - "sourceId": "HCXCXB", - "title": "Lazarus! How to stay safe from the biggest threat actor in crypto", - "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.", - "track": "Security", - "type": "Talk", + "id": "launching-projects-out-of-the-global-majority", + "sourceId": "7VZ8WH", + "title": "Launching Projects out of the Global Majority", + "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.", + "track": "Real World Ethereum", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Business", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Lazarus" + "Global" ], "tags": [ - "Security", + "DAO", + "Sufficient decentralization", "Best Practices", - "Hacks", - "lazarus", + "macro/micro economics", + "global", "Best Practices", - "Hacks", - "Security" + "DAO", + "macro/micro economics", + "Sufficient decentralization" ], "language": "en", "speakers": [ - "mudit-gupta" + "james-waugh" ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk" + "slot_start": 1731478800000, + "slot_end": 1731479400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc" }, "vector": [ - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -479288,7 +479680,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -479319,10 +479710,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -479392,6 +479783,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -479447,6 +479839,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -479504,6 +479897,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -479539,7 +479933,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -479850,14 +480243,15 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -479872,48 +480266,43 @@ }, { "session": { - "id": "learn-huff-to-become-an-evm-chad", - "sourceId": "HRMCBK", - "title": "Learn Huff to become an EVM chad", - "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.", - "track": "Developer Experience", - "type": "Workshop", + "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto", + "sourceId": "HCXCXB", + "title": "Lazarus! How to stay safe from the biggest threat actor in crypto", + "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.", + "track": "Security", + "type": "Talk", "expertise": "Intermediate", - "audience": "Developper", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Education", - "Huff", - "Programming" + "Lazarus" ], "tags": [ - "Tooling", - "Languages", - "Open Source Software", + "Security", "Best Practices", - "programming", + "Hacks", + "lazarus", "Best Practices", - "Languages", - "Open Source Software", - "Tooling" + "Hacks", + "Security" ], "language": "en", "speakers": [ - "clement-lakhal" + "mudit-gupta" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731571200000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU" + "slot_start": 1731580200000, + "slot_end": 1731582000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk" }, "vector": [ + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -480649,6 +481038,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -480668,7 +481060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -480744,8 +481135,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -480901,6 +481290,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -481049,10 +481440,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -481213,6 +481604,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -481221,7 +481613,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -481231,36 +481622,47 @@ }, { "session": { - "id": "lessons-and-learning-in-people-ops-at-the-ef", - "sourceId": "D7V8ZY", - "title": "Lessons & Learning in People Ops at the EF", - "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "learn-huff-to-become-an-evm-chad", + "sourceId": "HRMCBK", + "title": "Learn Huff to become an EVM chad", + "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "people", - "growth", - "open" + "Education", + "Huff", + "Programming" + ], + "tags": [ + "Tooling", + "Languages", + "Open Source Software", + "Best Practices", + "programming", + "Best Practices", + "Languages", + "Open Source Software", + "Tooling" ], - "tags": [], "language": "en", "speakers": [ - "jose-pedro-cabrita" + "clement-lakhal" ], "eventId": "devcon-7", - "slot_start": 1731652800000, - "slot_end": 1731654000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c" + "slot_start": 1731564000000, + "slot_end": 1731571200000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -481269,8 +481671,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -482019,6 +482419,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482028,6 +482429,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482093,6 +482495,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -482396,6 +482800,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482555,12 +482960,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -482572,44 +482977,36 @@ 0, 0, 0, - 0, - 0, - 0, 0 ] }, { "session": { - "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm", - "sourceId": "LL799L", - "title": "Lessons from integrating LogUp-GKR in the Miden VM", - "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.", - "track": "Applied Cryptography", + "id": "lessons-and-learning-in-people-ops-at-the-ef", + "sourceId": "D7V8ZY", + "title": "Lessons & Learning in People Ops at the EF", + "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.", + "track": "Coordination", "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "LogUp", - "GKR" - ], - "tags": [ - "Zero-Knowledge", - "Cryptography", - "gkr", - "Cryptography", - "Zero-Knowledge" + "people", + "growth", + "open" ], + "tags": [], "language": "en", "speakers": [ - "philippe-laferriere" + "jose-pedro-cabrita" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg" + "slot_start": 1731652800000, + "slot_end": 1731654000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c" }, "vector": [ 0, @@ -482622,6 +483019,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -483060,9 +483458,55 @@ 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, - 6, 0, 0, 0, @@ -483362,8 +483806,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -483756,45 +484198,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, @@ -483909,6 +484312,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -483916,12 +484320,6 @@ 0, 0, 2, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -483934,41 +484332,36 @@ }, { "session": { - "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia", - "sourceId": "F7Z87P", - "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia", - "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Local/SEA", + "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm", + "sourceId": "LL799L", + "title": "Lessons from integrating LogUp-GKR in the Miden VM", + "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Ethereum", - "Use", - "Cases" + "LogUp", + "GKR" ], "tags": [ - "Ethereum for Good", - "Climate", - "SEA", - "ethereum", - "case", - "use", - "Climate", - "Ethereum for Good", - "SEA" + "Zero-Knowledge", + "Cryptography", + "gkr", + "Cryptography", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "gesa-schneider" + "philippe-laferriere" ], "eventId": "devcon-7", - "slot_start": 1731574200000, - "slot_end": 1731574800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q" + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg" }, "vector": [ 0, @@ -483977,6 +484370,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -484417,12 +484814,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -484718,6 +485115,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -484835,7 +485234,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -484844,7 +485242,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -484954,7 +485351,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -485016,14 +485412,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -485115,6 +485509,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -485274,6 +485669,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -485286,46 +485682,46 @@ 0, 0, 0, - 0, - 2, 0 ] }, { "session": { - "id": "leveraging-high-performance-computing-for-efficient-stark-provers", - "sourceId": "ZGXYDF", - "title": "Leveraging High-Performance Computing for Efficient STARK Provers", - "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia", + "sourceId": "F7Z87P", + "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia", + "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Local/SEA", "featured": false, "doNotRecord": false, "keywords": [ - "computing performance", - "optimization", - "" + "Ethereum", + "Use", + "Cases" ], "tags": [ - "ZK-EVMs", - "ZKP", - "STARK", - "optimization", - "STARK", - "ZK-EVMs", - "ZKP" + "Ethereum for Good", + "Climate", + "SEA", + "ethereum", + "case", + "use", + "Climate", + "Ethereum for Good", + "SEA" ], "language": "en", "speakers": [ - "ricard-borrell" + "gesa-schneider" ], "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731479400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0" + "slot_start": 1731574200000, + "slot_end": 1731574800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q" }, "vector": [ 0, @@ -485334,12 +485730,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -486141,7 +486536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486195,6 +486589,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -486203,6 +486598,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -486277,7 +486673,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486314,6 +486709,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -486375,12 +486771,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -486414,8 +486812,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -486628,7 +487024,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486645,39 +487040,46 @@ 0, 0, 0, + 0, + 2, 0 ] }, { "session": { - "id": "light-client-support-in-prysm", - "sourceId": "9PC3EY", - "title": "Light Client Support in Prysm", - "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", + "id": "leveraging-high-performance-computing-for-efficient-stark-provers", + "sourceId": "ZGXYDF", + "title": "Leveraging High-Performance Computing for Efficient STARK Provers", + "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Prysm" + "computing performance", + "optimization", + "" ], "tags": [ - "EPF", - "Consensus", - "Light Clients" + "ZK-EVMs", + "ZKP", + "STARK", + "optimization", + "STARK", + "ZK-EVMs", + "ZKP" ], "language": "en", "speakers": [ - "bastin", - "rupam" + "ricard-borrell" ], "eventId": "devcon-7", - "slot_start": 1731474900000, - "slot_end": 1731475800000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q" + "slot_start": 1731477600000, + "slot_end": 1731479400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0" }, "vector": [ 0, @@ -486690,11 +487092,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -487133,48 +487530,11 @@ 0, 0, 0, - 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -487423,7 +487783,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -487438,7 +487797,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -487538,6 +487896,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -487675,6 +488034,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -487721,7 +488081,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -487810,6 +488169,50 @@ 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, @@ -488002,47 +488405,34 @@ }, { "session": { - "id": "lighthouse-introduction-to-siren", - "sourceId": "F3ZPRJ", - "title": "Lighthouse: Introduction to Siren", - "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.", - "track": "Usability", + "id": "light-client-support-in-prysm", + "sourceId": "9PC3EY", + "title": "Light Client Support in Prysm", + "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.", + "track": "[CLS] EPF Day", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Home staking", - "UI/UX", - "Accessibility", - "ui", - "Accessibility", - "Home staking", - "UI/UX" - ], "keywords": [ - "lighthouse", - "UI" + "Prysm" + ], + "tags": [ + "EPF", + "Consensus", + "Light Clients" ], - "duration": 388, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "RhlKmJqk0go", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt", - "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.", - "eventId": "devcon-7", - "slot_start": 1731408000000, - "slot_end": 1731408600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w", - "resources_slides": null, "speakers": [ - "ricki-moore" - ] + "bastin", + "rupam" + ], + "eventId": "devcon-7", + "slot_start": 1731475800000, + "slot_end": 1731476700000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q" }, "vector": [ 0, @@ -488053,9 +488443,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -488063,6 +488450,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -488501,6 +488889,8 @@ 0, 0, 6, + 6, + 0, 0, 0, 0, @@ -488789,6 +489179,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -488803,6 +489194,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -488842,8 +489234,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -488869,7 +489259,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -489089,6 +489478,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -489190,7 +489580,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -489351,11 +489740,13 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -489367,34 +489758,47 @@ }, { "session": { - "id": "lighthouse-transition-journey-from-warp-to-axum", - "sourceId": "ZF79GZ", - "title": "Lighthouse transition journey : from warp to axum", - "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes", - "track": "[CLS] EPF Day", + "id": "lighthouse-introduction-to-siren", + "sourceId": "F3ZPRJ", + "title": "Lighthouse: Introduction to Siren", + "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.", + "track": "Usability", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, - "keywords": [ - "Performance", - "Developer", - "experience" - ], "tags": [ - "Developer Infrastructure", - "Light Clients" + "Home staking", + "UI/UX", + "Accessibility", + "ui", + "Accessibility", + "Home staking", + "UI/UX" ], - "language": "en", - "speakers": [ - "lea-narzis" + "keywords": [ + "lighthouse", + "UI" ], + "duration": 388, + "language": "en", + "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4", + "sources_youtubeId": "RhlKmJqk0go", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt", + "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.", "eventId": "devcon-7", - "slot_start": 1731473100000, - "slot_end": 1731474000000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM" + "slot_start": 1731408000000, + "slot_end": 1731408600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w", + "resources_slides": null, + "speakers": [ + "ricki-moore" + ] }, "vector": [ 0, @@ -489405,6 +489809,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -489412,8 +489817,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -490155,8 +490558,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -490189,7 +490590,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -490199,6 +490599,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -490224,6 +490626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -490544,6 +490947,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -490697,7 +491101,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -490709,6 +491112,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -490719,37 +491124,34 @@ }, { "session": { - "id": "liquid-staking-for-daos", - "sourceId": "ZV39SQ", - "title": "Liquid Staking for DAOs", - "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "lighthouse-transition-journey-from-warp-to-axum", + "sourceId": "ZF79GZ", + "title": "Lighthouse transition journey : from warp to axum", + "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "DAOs" + "Performance", + "Developer", + "experience" ], "tags": [ - "Coordination", - "DAO", - "Best Practices", - "Mechanism design", - "Best Practices", - "Coordination", - "Mechanism design" + "Developer Infrastructure", + "Light Clients" ], "language": "en", "speakers": [ - "dennison-bertram" + "lea-narzis" ], "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731396600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww" + "slot_start": 1731474000000, + "slot_end": 1731474900000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM" }, "vector": [ 0, @@ -490763,6 +491165,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -491204,12 +491610,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -491497,7 +491903,27 @@ 0, 0, 0, - 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -491591,7 +492017,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -491645,33 +492070,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, @@ -492054,6 +492452,13 @@ 0, 0, 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -492061,8 +492466,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -492074,25 +492477,37 @@ }, { "session": { - "id": "liron-achdut", - "sourceId": "TPPWYB", - "title": "Liron Achdut", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "liquid-staking-for-daos", + "sourceId": "ZV39SQ", + "title": "Liquid Staking for DAOs", + "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "DAOs" + ], + "tags": [ + "Coordination", + "DAO", + "Best Practices", + "Mechanism design", + "Best Practices", + "Coordination", + "Mechanism design" + ], "language": "en", - "speakers": [], + "speakers": [ + "dennison-bertram" + ], "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731657600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo" + "slot_start": 1731394800000, + "slot_end": 1731396600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww" }, "vector": [ 0, @@ -492104,12 +492519,9 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -492555,6 +492967,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -492843,6 +493256,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -492866,6 +493280,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -492935,6 +493350,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -492988,6 +493404,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -493399,12 +493816,11 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -493417,35 +493833,25 @@ }, { "session": { - "id": "little-things-weve-learned-about-fhe", - "sourceId": "9JFDZA", - "title": "Little Things We've learned About FHE", - "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", + "id": "liron-achdut", + "sourceId": "TPPWYB", + "title": "Liron Achdut", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ELI5" - ], - "tags": [ - "Cryptography", - "Homomorphic Encryption", - "eli5", - "Cryptography", - "Homomorphic Encryption" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "chih-cheng-liang" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k" + "slot_start": 1731654000000, + "slot_end": 1731657600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo" }, "vector": [ 0, @@ -493457,7 +493863,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -493906,7 +494311,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -494199,7 +494603,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -494276,7 +494679,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -494594,7 +494996,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -494748,13 +495149,19 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, 0, 0, 0, 2, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -494770,27 +495177,35 @@ }, { "session": { - "id": "live-music-open-jam-or-something-in-between", - "sourceId": "FVHR9Y", - "title": "Live Music, Open Jam, Or Something In Between", - "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.", - "track": "Entertainment", - "type": "Music", + "id": "little-things-weve-learned-about-fhe", + "sourceId": "9JFDZA", + "title": "Little Things We've learned About FHE", + "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "ELI5" + ], + "tags": [ + "Cryptography", + "Homomorphic Encryption", + "eli5", + "Cryptography", + "Homomorphic Encryption" + ], "language": "en", "speakers": [ - "marc-nitzsche" + "chih-cheng-liang" ], "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731481200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k" }, "vector": [ 0, @@ -494802,9 +495217,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -495546,6 +495960,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -495622,6 +496037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -495939,7 +496355,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -496097,12 +496513,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -496115,34 +496531,27 @@ }, { "session": { - "id": "liveops-for-autonomous-worlds", - "sourceId": "DGU8PN", - "title": "Liveops for autonomous worlds", - "description": "How do you keep a world alive, especially one that is deliberately ownerless and autonomous?\r\n\r\nAs creators and stewards of a world, how should you react and not react to certain events unfolding in the world? \r\n\r\nWe will share our experience and learnings from running This Cursed Machine and previous projects.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "live-music-open-jam-or-something-in-between", + "sourceId": "FVHR9Y", + "title": "Live Music, Open Jam, Or Something In Between", + "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.", + "track": "Entertainment", + "type": "Music", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" - ], + "tags": [], "language": "en", "speakers": [ - "arthur-roing-baer", - "alex-declino", - "rasmus-svensson" + "marc-nitzsche" ], "eventId": "devcon-7", - "slot_start": 1731567000000, - "slot_end": 1731568500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk" + "slot_start": 1731477600000, + "slot_end": 1731481200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4" }, "vector": [ 0, @@ -496154,11 +496563,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -496606,8 +497014,6 @@ 0, 0, 6, - 6, - 6, 0, 0, 0, @@ -496993,37 +497399,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -497447,7 +497822,43 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -497461,46 +497872,39 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "local-build-why-language-is-key-to-decentralization", - "sourceId": "UHVBNL", - "title": "Local Build: Why language is key to decentralization", - "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "liveops-for-autonomous-worlds", + "sourceId": "DGU8PN", + "title": "Liveops for autonomous worlds", + "description": "How do you keep a world alive, especially one that is deliberately ownerless and autonomous?\r\n\r\nAs creators and stewards of a world, how should you react and not react to certain events unfolding in the world? \r\n\r\nWe will share our experience and learnings from running This Cursed Machine and previous projects.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Internationalization", - "Localization" - ], + "keywords": [], "tags": [ - "Decentralization Improvements", - "Languages", - "User Experience", - "localization", - "l10n", - "Decentralization Improvements", - "Languages", - "User Experience" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "oliver-jl-renwick", - "laurel" + "arthur-roing-baer", + "alex-declino", + "rasmus-svensson" ], "eventId": "devcon-7", - "slot_start": 1731490800000, - "slot_end": 1731491400000, + "slot_start": 1731579300000, + "slot_end": 1731580800000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0" + "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk" }, "vector": [ 0, @@ -497514,6 +497918,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -497962,12 +498367,13 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -498247,7 +498653,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -498257,7 +498662,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -498338,7 +498742,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -498353,6 +498756,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -498650,8 +499056,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -498803,10 +499207,11 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -498825,39 +499230,40 @@ }, { "session": { - "id": "logs-for-you-anon", - "sourceId": "RRYVNW", - "title": "Logs for you anon", - "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.", - "track": "Cypherpunk & Privacy", + "id": "local-build-why-language-is-key-to-decentralization", + "sourceId": "UHVBNL", + "title": "Local Build: Why language is key to decentralization", + "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "logs", - "local apps", - "indexing" + "Internationalization", + "Localization" ], "tags": [ - "DevEx", - "Privacy", - "Decentralization", - "indexing", - "Decentralization", - "DevEx", - "Privacy" + "Decentralization Improvements", + "Languages", + "User Experience", + "localization", + "l10n", + "Decentralization Improvements", + "Languages", + "User Experience" ], "language": "en", "speakers": [ - "yabir-garcia-benchakhtir" + "oliver-jl-renwick", + "laurel" ], "eventId": "devcon-7", - "slot_start": 1731646200000, - "slot_end": 1731646800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ" + "slot_start": 1731490800000, + "slot_end": 1731491400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0" }, "vector": [ 0, @@ -498865,15 +499271,13 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -499326,6 +499730,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -499606,6 +500011,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -499615,6 +500021,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -499628,7 +500035,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -499696,11 +500102,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -499715,7 +500121,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -500010,6 +500415,8 @@ 0, 0, 2, + 2, + 0, 0, 0, 0, @@ -500164,11 +500571,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -500182,46 +500589,47 @@ }, { "session": { - "id": "long-term-decentralized-storage-for-blobs", - "sourceId": "RCVFHX", - "title": "Long-term Decentralized Storage for Blobs", - "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.", - "track": "Core Protocol", + "id": "logs-for-you-anon", + "sourceId": "RRYVNW", + "title": "Logs for you anon", + "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.", + "track": "Cypherpunk & Privacy", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Storage" + "logs", + "local apps", + "indexing" ], "tags": [ - "Core Protocol", - "Blobs", - "Sustainability", - "storage", - "Blobs", - "Core Protocol", - "Sustainability" + "DevEx", + "Privacy", + "Decentralization", + "indexing", + "Decentralization", + "DevEx", + "Privacy" ], "language": "en", "speakers": [ - "leo-bautista-gomez" + "yabir-garcia-benchakhtir" ], "eventId": "devcon-7", - "slot_start": 1731469800000, - "slot_end": 1731470400000, + "slot_start": 1731646200000, + "slot_end": 1731646800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M" + "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -500972,7 +501380,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -500986,6 +501393,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -501017,7 +501425,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501058,6 +501465,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -501071,6 +501480,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -501303,7 +501713,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501515,15 +501924,16 @@ 0, 0, 0, + 0, 2, 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -501537,44 +501947,43 @@ }, { "session": { - "id": "lunarpunk-endgame", - "sourceId": "EVHFWA", - "title": "Lunarpunk Endgame", - "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": true, + "id": "long-term-decentralized-storage-for-blobs", + "sourceId": "RCVFHX", + "title": "Long-term Decentralized Storage for Blobs", + "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, "doNotRecord": false, "keywords": [ - "Lunarpunk" + "Storage" ], "tags": [ - "Network State", - "Anonymity", - "Autonomous World", - "lunarpunk", - "Anonymity", - "Autonomous World", - "Network State" + "Core Protocol", + "Blobs", + "Sustainability", + "storage", + "Blobs", + "Core Protocol", + "Sustainability" ], "language": "en", "speakers": [ - "rachel-rose-oleary" + "leo-bautista-gomez" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4" + "slot_start": 1731469800000, + "slot_end": 1731470400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -502329,11 +502738,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -502355,9 +502759,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -502382,6 +502783,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -502418,7 +502820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -502668,6 +503069,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -502721,7 +503123,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -502730,6 +503131,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -502872,7 +503280,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -502882,6 +503289,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -502892,47 +503303,37 @@ }, { "session": { - "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to", - "sourceId": "TCJJW3", - "title": "MACI - Why do we need private voting and what are we up to", - "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "lunarpunk-endgame", + "sourceId": "EVHFWA", + "title": "Lunarpunk Endgame", + "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", - "featured": false, + "featured": true, "doNotRecord": false, - "tags": [ - "Coordination", - "Quadratic Voting", - "Public good", - "voting", - "Coordination", - "Public good", - "Quadratic Voting" - ], "keywords": [ - "Privacy", - "Voting" + "Lunarpunk" + ], + "tags": [ + "Network State", + "Anonymity", + "Autonomous World", + "lunarpunk", + "Anonymity", + "Autonomous World", + "Network State" ], - "duration": 606, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "18KFAia72Ww", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt", - "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.", - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731395400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg", - "resources_slides": null, "speakers": [ - "ctrlc03" - ] + "rachel-rose-oleary" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4" }, "vector": [ 0, @@ -502940,13 +503341,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -503701,6 +504101,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -503720,6 +504122,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -503828,7 +504231,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -503882,7 +504284,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504034,7 +504435,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504088,6 +504488,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -504235,12 +504636,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -504257,39 +504659,47 @@ }, { "session": { - "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses", - "sourceId": "RGMXQ7", - "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses", - "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.", - "track": "Cypherpunk & Privacy", + "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to", + "sourceId": "TCJJW3", + "title": "MACI - Why do we need private voting and what are we up to", + "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.", + "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "d/acc", - "adoption", - "messaging" - ], "tags": [ - "Frameworks", - "Values", - "Use cases of cryptography", - "messaging", - "Frameworks", - "Use cases of cryptography", - "Values" + "Coordination", + "Quadratic Voting", + "Public good", + "voting", + "Coordination", + "Public good", + "Quadratic Voting" ], - "language": "en", - "speakers": [ - "vivek-bhupatiraju" + "keywords": [ + "Privacy", + "Voting" ], + "duration": 606, + "language": "en", + "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6", + "sources_youtubeId": "18KFAia72Ww", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt", + "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.", "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731496200000, + "slot_start": 1731394800000, + "slot_end": 1731395400000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE" + "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg", + "resources_slides": null, + "speakers": [ + "ctrlc03" + ] }, "vector": [ 0, @@ -504297,12 +504707,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -504560,7 +504970,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -504761,6 +505170,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -505058,7 +505468,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -505135,7 +505544,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -505188,6 +505596,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505243,6 +505652,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505392,6 +505802,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505444,8 +505855,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -505598,9 +506007,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -505614,31 +506025,41 @@ }, { "session": { - "id": "manu-alzuru", - "sourceId": "GNMHSF", - "title": "Manu Alzuru", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses", + "sourceId": "RGMXQ7", + "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses", + "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "d/acc", + "adoption", + "messaging" + ], + "tags": [ + "Frameworks", + "Values", + "Use cases of cryptography", + "messaging", + "Frameworks", + "Use cases of cryptography", + "Values" + ], "language": "en", - "speakers": [], + "speakers": [ + "vivek-bhupatiraju" + ], "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731661200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM" + "slot_start": 1731495600000, + "slot_end": 1731496200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE" }, "vector": [ - 0, - 0, - 0, - 0, 0, 0, 0, @@ -505907,6 +506328,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -506405,6 +506827,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -506481,12 +506904,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -506788,6 +507213,52 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -506892,59 +507363,14 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, 2, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -506957,43 +507383,32 @@ }, { "session": { - "id": "maximum-viable-security-mvs-a-new-issuance-framework", - "sourceId": "KWUF3N", - "title": "Maximum Viable Security (MVS) – a new issuance framework", - "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "manu-alzuru", + "sourceId": "GNMHSF", + "title": "Manu Alzuru", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "neutrality", - "autonomy", - "validator set composition" - ], - "tags": [ - "Staking", - "Validator Experience", - "Security", - "composability", - "validator", - "set", - "Security", - "Staking", - "Validator Experience" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "artem-kotelskiy" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo" + "slot_start": 1731657600000, + "slot_end": 1731661200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -507463,7 +507878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -507732,7 +508146,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -507770,7 +508183,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -507861,7 +508273,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -508147,9 +508558,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -508294,7 +508702,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -508302,6 +508709,10 @@ 2, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -508316,44 +508727,48 @@ }, { "session": { - "id": "memecraft-effectively-communicating-crypto-concepts", - "sourceId": "FAKRPS", - "title": "Memecraft: Effectively Communicating Crypto Concepts", - "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.", - "track": "Coordination", + "id": "maximum-viable-security-mvs-a-new-issuance-framework", + "sourceId": "KWUF3N", + "title": "Maximum Viable Security (MVS) – a new issuance framework", + "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.", + "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "memes" + "neutrality", + "autonomy", + "validator set composition" ], "tags": [ - "Public good", - "Marketing", - "User Research", - "memes", - "Marketing", - "Public good", - "User Research" + "Staking", + "Validator Experience", + "Security", + "composability", + "validator", + "set", + "Security", + "Staking", + "Validator Experience" ], "language": "en", "speakers": [ - "joshua-davila", - "beth-mccarthy" + "artem-kotelskiy" ], "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731643800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I" + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -508361,8 +508776,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -508821,7 +509234,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -509091,6 +509503,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -509128,6 +509541,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -509175,7 +509589,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -509197,7 +509610,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -509220,6 +509632,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -509377,7 +509790,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -509507,6 +509919,9 @@ 0, 0, 2, + 2, + 2, + 0, 0, 0, 0, @@ -509655,11 +510070,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -509672,37 +510087,51 @@ }, { "session": { - "id": "merkle-proofs-when-leaves-leave-you-vulnerable", - "sourceId": "LAKCG3", - "title": "Merkle Proofs: When Leaves Leave You Vulnerable", - "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.", - "track": "Security", - "type": "Lightning Talk", + "id": "memecraft-effectively-communicating-crypto-concepts", + "sourceId": "FAKRPS", + "title": "Memecraft: Effectively Communicating Crypto Concepts", + "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.", + "track": "Coordination", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Merkle" + "memes" ], "tags": [ - "Auditing", - "Bug", - "merkle", - "Auditing", - "Bug" + "Public good", + "Marketing", + "User Research", + "memes", + "Marketing", + "Public good", + "User Research" ], "language": "en", "speakers": [ - "shufan-wang" + "joshua-davila", + "beth-mccarthy" ], "eventId": "devcon-7", - "slot_start": 1731390000000, - "slot_end": 1731390600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c" + "slot_start": 1731642000000, + "slot_end": 1731643800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -510162,6 +510591,10 @@ 0, 0, 0, + 6, + 6, + 0, + 0, 0, 0, 0, @@ -510175,7 +510608,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -510515,6 +510947,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -510535,6 +510969,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -510593,7 +511029,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -510843,6 +511278,33 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -510860,49 +511322,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, @@ -511007,12 +511426,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -511025,48 +511444,38 @@ }, { "session": { - "id": "modern-zkp-compilers", - "sourceId": "CV7QXP", - "title": "Modern ZKP compilers", - "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize", - "track": "Applied Cryptography", + "id": "merkle-proofs-when-leaves-leave-you-vulnerable", + "sourceId": "LAKCG3", + "title": "Merkle Proofs: When Leaves Leave You Vulnerable", + "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.", + "track": "Security", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "Languages", - "ZKP", - "education", - "Developer Infrastructure", - "Languages", - "ZKP" - ], "keywords": [ - "education" + "Merkle" + ], + "tags": [ + "Auditing", + "Bug", + "merkle", + "Auditing", + "Bug" ], - "duration": 645, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "JX9YtcG_EHk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt", - "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.", - "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731393600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ", - "resources_slides": null, "speakers": [ - "leo-lara" - ] + "shufan-wang" + ], + "eventId": "devcon-7", + "slot_start": 1731390000000, + "slot_end": 1731390600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c" }, "vector": [ + 6, 0, 0, 0, @@ -511077,8 +511486,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -511859,7 +512266,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511880,7 +512286,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511896,13 +512301,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -511963,6 +512366,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -512082,6 +512489,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512225,6 +512633,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512389,43 +512798,48 @@ }, { "session": { - "id": "molecular-verification-tools-to-enhance-public-trust-during-pandemic-response", - "sourceId": "BRUGUL", - "title": "Molecular verification tools to enhance public trust during pandemic response", - "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "modern-zkp-compilers", + "sourceId": "CV7QXP", + "title": "Modern ZKP compilers", + "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize", + "track": "Applied Cryptography", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Molecular", - "Biology.", - "", - "Public", - "Health.", - "", - "Public", - "Trust." - ], "tags": [ - "Decentralization", - "Public good" + "Developer Infrastructure", + "Languages", + "ZKP", + "education", + "Developer Infrastructure", + "Languages", + "ZKP" ], - "language": "en", - "speakers": [ - "phillip-j-buckhaults" + "keywords": [ + "education" ], + "duration": 645, + "language": "en", + "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c", + "sources_youtubeId": "JX9YtcG_EHk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt", + "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.", "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731571800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI" + "slot_start": 1731393000000, + "slot_end": 1731393600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ", + "resources_slides": null, + "speakers": [ + "leo-lara" + ] }, "vector": [ - 0, - 6, 0, 0, 0, @@ -512436,6 +512850,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -513218,6 +513633,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -513238,6 +513654,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -513253,25 +513670,25 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -513728,7 +514145,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -513741,40 +514157,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "mood-rebalancing-singing-bowls-handpan", - "sourceId": "SVAHJU", - "title": "Mood Rebalancing (Singing Bowls + Handpan)", - "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", + "id": "molecular-verification-tools-to-enhance-public-trust-during-pandemic-response", + "sourceId": "BRUGUL", + "title": "Molecular verification tools to enhance public trust during pandemic response", + "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Molecular", + "Biology.", + "", + "Public", + "Health.", + "", + "Public", + "Trust." + ], + "tags": [ + "Decentralization", + "Public good" + ], "language": "en", - "speakers": [], + "speakers": [ + "phillip-j-buckhaults" + ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731644100000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw" + "slot_start": 1731571200000, + "slot_end": 1731571800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 6, 0, @@ -514249,6 +514672,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -514615,6 +515039,39 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -515042,40 +515499,15 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -515089,10 +515521,10 @@ }, { "session": { - "id": "mood-uplifting-singing-bowls-handpan", - "sourceId": "H7Y7L8", - "title": "Mood Uplifting (Singing Bowls + Handpan)", - "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45", + "id": "mood-rebalancing-singing-bowls-handpan", + "sourceId": "SVAHJU", + "title": "Mood Rebalancing (Singing Bowls + Handpan)", + "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15", "track": "Entertainment", "type": "Mixed Formats", "expertise": "", @@ -515104,10 +515536,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731573900000, + "slot_start": 1731641400000, + "slot_end": 1731644100000, "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw" + "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw" }, "vector": [ 0, @@ -516411,6 +516843,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -516432,48 +516865,25 @@ }, { "session": { - "id": "mopro-make-client-side-proving-on-mobile-easy", - "sourceId": "BZWFEM", - "title": "Mopro: Make Client-side Proving on Mobile Easy", - "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", + "id": "mood-uplifting-singing-bowls-handpan", + "sourceId": "H7Y7L8", + "title": "Mood Uplifting (Singing Bowls + Handpan)", + "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "ZKP", - "Cryptography", - "Mobile", - "android", - "Cryptography", - "Mobile", - "ZKP" - ], - "keywords": [ - "iOS", - "Android" - ], - "duration": 958, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "0ziKiYwhJHk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt", - "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731397800000, - "slot_end": 1731398400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk", - "resources_slides": null, - "speakers": [ - "ya-wen-jeng", - "moven-tsai" - ] + "slot_start": 1731571200000, + "slot_end": 1731573900000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw" }, "vector": [ 0, @@ -516485,7 +516895,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -516951,8 +517360,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -517227,7 +517634,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -517237,7 +517643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -517289,7 +517694,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -517576,7 +517980,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -517776,12 +518179,18 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -517793,42 +518202,55 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on", - "sourceId": "9JYWVP", - "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.", - "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.", + "id": "mopro-make-client-side-proving-on-mobile-easy", + "sourceId": "BZWFEM", + "title": "Mopro: Make Client-side Proving on Mobile Easy", + "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.", "track": "Applied Cryptography", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [ - "FHE", - "MPC", - "Explorations" - ], "tags": [ - "Homomorphic Encryption", - "Use cases of cryptography", - "exploration", - "Homomorphic Encryption", - "Use cases of cryptography" + "ZKP", + "Cryptography", + "Mobile", + "android", + "Cryptography", + "Mobile", + "ZKP" ], - "language": "en", - "speakers": [ - "cperezz" + "keywords": [ + "iOS", + "Android" ], + "duration": 958, + "language": "en", + "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649", + "sources_youtubeId": "0ziKiYwhJHk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt", + "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you", "eventId": "devcon-7", - "slot_start": 1731391800000, - "slot_end": 1731392400000, + "slot_start": 1731397800000, + "slot_end": 1731398400000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY" + "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk", + "resources_slides": null, + "speakers": [ + "ya-wen-jeng", + "moven-tsai" + ] }, "vector": [ 0, @@ -518306,8 +518728,7 @@ 0, 0, 0, - 0, - 0, + 6, 6, 0, 0, @@ -518584,6 +519005,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -518593,11 +519015,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -518645,6 +519067,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -518659,7 +519082,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -518932,6 +519354,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -518989,7 +519413,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -519135,9 +519558,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -519153,46 +519576,37 @@ }, { "session": { - "id": "mpc-tooling-or-how-to-create-mpc-apps", - "sourceId": "QLMYBD", - "title": "MPC Tooling or How to create MPC apps", - "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.", + "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on", + "sourceId": "9JYWVP", + "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.", + "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.", "track": "Applied Cryptography", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Tooling", - "Cryptography", - "MPC", - "Cryptography", + "keywords": [ + "FHE", "MPC", - "Tooling" + "Explorations" ], - "keywords": [ - "Circom-MPC", - "MPC tooling" + "tags": [ + "Homomorphic Encryption", + "Use cases of cryptography", + "exploration", + "Homomorphic Encryption", + "Use cases of cryptography" ], - "duration": 489, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "eKpcf1JMNak", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt", - "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume", + "speakers": [ + "cperezz" + ], "eventId": "devcon-7", - "slot_start": 1731390600000, - "slot_end": 1731391200000, + "slot_start": 1731391800000, + "slot_end": 1731392400000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE", - "resources_slides": null, - "speakers": [ - "rasul-ibragimov" - ] + "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY" }, "vector": [ 0, @@ -519672,7 +520086,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -519946,24 +520359,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -519981,6 +520376,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -520022,7 +520418,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -520043,6 +520438,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -520372,6 +520768,25 @@ 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, @@ -520517,35 +520932,46 @@ }, { "session": { - "id": "mpc101-what-is-multi-party-computation", - "sourceId": "UTYK7X", - "title": "MPC101: What is Multi-party Computation?", - "description": "This workshop provides an in-depth introduction to Multiparty Computation (MPC), focusing on its principles, protocols, and practical applications. Participants will learn how to design and implement MPC solutions, enabling secure collaborative computing without compromising data privacy.", + "id": "mpc-tooling-or-how-to-create-mpc-apps", + "sourceId": "QLMYBD", + "title": "MPC Tooling or How to create MPC apps", + "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.", "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "MPC101" - ], "tags": [ - "Privacy", + "Tooling", + "Cryptography", "MPC", - "mpc101", + "Cryptography", "MPC", - "Privacy" + "Tooling" ], - "language": "en", - "speakers": [ - "vanishree-rao" + "keywords": [ + "Circom-MPC", + "MPC tooling" ], + "duration": 489, + "language": "en", + "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa", + "sources_youtubeId": "eKpcf1JMNak", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt", + "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume", "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731656400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1_q4yi8p91iDLVndotuvo2cF9YthOVkTSawv6R3pIaKY" + "slot_start": 1731390600000, + "slot_end": 1731391200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE", + "resources_slides": null, + "speakers": [ + "rasul-ibragimov" + ] }, "vector": [ 0, @@ -521026,7 +521452,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -521301,6 +521726,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -521308,6 +521734,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -521403,8 +521830,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -521707,7 +522132,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -521853,6 +522277,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -521865,59 +522291,41 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "mpcstats", - "sourceId": "ND3S9R", - "title": "MPCStats", - "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.", + "id": "mpc101-what-is-multi-party-computation", + "sourceId": "UTYK7X", + "title": "MPC101: What is Multi-party Computation?", + "description": "This workshop provides an in-depth introduction to Multiparty Computation (MPC), focusing on its principles, protocols, and practical applications. Participants will learn how to design and implement MPC solutions, enabling secure collaborative computing without compromising data privacy.", "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, + "keywords": [ + "MPC101" + ], "tags": [ - "Tooling", "Privacy", "MPC", - "Public good", - "verification", - "computation", - "MPC", - "Privacy", - "Public good", - "Tooling" - ], - "keywords": [ - "privacy-preserving", - "data analysis", + "mpc101", "MPC", - "statistics", - "verifiable computation" + "Privacy" ], - "duration": 508, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "wCp7Zsjou7w", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt", - "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you", - "eventId": "devcon-7", - "slot_start": 1731396000000, - "slot_end": 1731396600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8", - "resources_slides": null, "speakers": [ - "kevin-chia", - "teeramet-jern-kunpittaya" - ] + "vanishree-rao" + ], + "eventId": "devcon-7", + "slot_start": 1731655800000, + "slot_end": 1731656400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1_q4yi8p91iDLVndotuvo2cF9YthOVkTSawv6R3pIaKY" }, "vector": [ 0, @@ -522399,8 +522807,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -522679,7 +523085,10 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -522767,7 +523176,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -523005,7 +523414,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -523220,12 +523628,13 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, 2, 0, + 2, 0, 0, 0, @@ -523242,51 +523651,56 @@ }, { "session": { - "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up", - "sourceId": "883QBY", - "title": "MUD - How we built an EVM application framework from the ground up", - "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.", - "track": "Developer Experience", - "type": "Talk", + "id": "mpcstats", + "sourceId": "ND3S9R", + "title": "MPCStats", + "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.", + "track": "Applied Cryptography", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Onchain", - "Games" - ], "tags": [ - "DevEx", - "Frameworks", - "Gaming", - "Autonomous World", - "onchain", - "Autonomous World", - "DevEx", - "Frameworks" + "Tooling", + "Privacy", + "MPC", + "Public good", + "verification", + "computation", + "MPC", + "Privacy", + "Public good", + "Tooling" ], - "language": "en", - "speakers": [ - "alvarius" + "keywords": [ + "privacy-preserving", + "data analysis", + "MPC", + "statistics", + "verifiable computation" ], + "duration": 508, + "language": "en", + "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51", + "sources_youtubeId": "wCp7Zsjou7w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt", + "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you", "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE" + "slot_start": 1731396000000, + "slot_end": 1731396600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8", + "resources_slides": null, + "speakers": [ + "kevin-chia", + "teeramet-jern-kunpittaya" + ] }, "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -523297,6 +523711,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -523391,7 +523806,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -523767,6 +524181,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -524113,19 +524529,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 2, 2, 0, 0, @@ -524146,6 +524549,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -524153,6 +524557,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -524382,6 +524787,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -524438,25 +524844,44 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -524599,39 +525024,45 @@ }, { "session": { - "id": "multi-party-fhe-for-multi-player-privacy", - "sourceId": "S9S8M9", - "title": "Multi-Party FHE for Multi-Player Privacy", - "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.", - "track": "Applied Cryptography", - "type": "Panel", - "expertise": "Beginner", + "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up", + "sourceId": "883QBY", + "title": "MUD - How we built an EVM application framework from the ground up", + "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "mp", - "fhe", - "programmable cryptography" + "Onchain", + "Games" + ], + "tags": [ + "DevEx", + "Frameworks", + "Gaming", + "Autonomous World", + "onchain", + "Autonomous World", + "DevEx", + "Frameworks" ], - "tags": [], "language": "en", "speakers": [ - "gubsheep", - "veronica-zheng", - "eduard-sanou", - "janmajaya-mall" + "alvarius" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731567600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI" + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -524639,8 +525070,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -524744,6 +525173,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -524757,7 +525187,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -524816,7 +525245,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -525049,7 +525477,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -525111,7 +525538,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -525402,6 +525828,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525476,10 +525903,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -525791,6 +526221,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525929,9 +526360,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 2, 0, @@ -525951,36 +526382,32 @@ }, { "session": { - "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice", - "sourceId": "QC7FH7", - "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice", - "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "", + "id": "mud-past-present-and-future", + "sourceId": "FE9L3P", + "title": "MUD: Past, present, and future", + "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Programmable", - "Cryptography" - ], + "keywords": [], "tags": [ - "Cryptography", - "Homomorphic Encryption" + "Autonomous World", + "Frameworks", + "Gaming", + "Tooling" ], "language": "en", "speakers": [ - "gubsheep", - "riley-wong-theythem", - "eduard-sanou", - "han-jian" + "alvarius" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731654000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM" + "slot_start": 1731553200000, + "slot_end": 1731554400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE" }, "vector": [ 0, @@ -525995,9 +526422,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -526097,6 +526524,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -526170,7 +526599,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -526465,9 +526893,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -526734,7 +527159,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -526746,6 +527170,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -526811,7 +527236,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -526830,10 +527254,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -527283,10 +527710,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, @@ -527297,7 +527726,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -527305,38 +527733,34 @@ }, { "session": { - "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors", - "sourceId": "KS7H3H", - "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors", - "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).", + "id": "multi-party-fhe-for-multi-player-privacy", + "sourceId": "S9S8M9", + "title": "Multi-Party FHE for Multi-Player Privacy", + "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.", "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "type": "Panel", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [ - "Open Source Software", - "Homomorphic Encryption", - "Use cases of cryptography", - "Security", - "Use Cases", - "Homomorphic Encryption", - "Open Source Software", - "Security", - "Use Cases", - "Use cases of cryptography" + "keywords": [ + "mp", + "fhe", + "programmable cryptography" ], + "tags": [], "language": "en", "speakers": [ - "jean-philippe-bossuat" + "gubsheep", + "veronica-zheng", + "eduard-sanou", + "janmajaya-mall" ], "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, + "slot_start": 1731564000000, + "slot_end": 1731567600000, "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA" + "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI" }, "vector": [ 0, @@ -527467,6 +527891,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -527523,6 +527950,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -527755,6 +528183,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -527816,6 +528245,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -527824,7 +528254,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -528077,7 +528506,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -528105,7 +528533,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -528156,7 +528583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -528167,7 +528593,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -528175,7 +528600,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -528639,10 +529063,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 2, 0, @@ -528656,39 +529080,42 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "my-mother-will-not-use-it", - "sourceId": "HKKFQX", - "title": "\"My mother will not use it\"", - "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.", - "track": "Usability", - "type": "Lightning Talk", + "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice", + "sourceId": "QC7FH7", + "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice", + "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Design", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "Inspiration" + "Programmable", + "Cryptography" ], "tags": [ - "inspiration", - "Design", - "Design Thinking", - "UI/UX" + "Cryptography", + "Homomorphic Encryption" ], "language": "en", "speakers": [ - "nuno-loureiro" + "gubsheep", + "riley-wong-theythem", + "eduard-sanou", + "han-jian" ], "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731560400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc" + "slot_start": 1731648600000, + "slot_end": 1731654000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM" }, "vector": [ 0, @@ -528699,18 +529126,13 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -528883,6 +529305,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -529178,6 +529601,8 @@ 0, 0, 6, + 6, + 6, 0, 0, 0, @@ -529445,6 +529870,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -529488,7 +529914,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -529522,6 +529947,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -529572,8 +529999,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -529853,7 +530278,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -529991,11 +530415,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -530008,60 +530435,44 @@ 0, 2, 0, + 0, 0 ] }, { "session": { - "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond", - "sourceId": "8CDPFC", - "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond", - "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors", + "sourceId": "KS7H3H", + "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors", + "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, + "keywords": [], "tags": [ - "Collective Intelligence", - "Conviction", - "Consensus Mechanisms", - "Civil Resistance", - "Sustainability", - "Public good", - "Regenerative Applications", - "Design Thinking", - "Civil Resistance", - "Collective Intelligence", - "Consensus Mechanisms", - "Conviction", - "Design Thinking", - "Public good", - "Regenerative Applications", - "Sustainability" - ], - "keywords": [ - "nope" + "Open Source Software", + "Homomorphic Encryption", + "Use cases of cryptography", + "Security", + "Use Cases", + "Homomorphic Encryption", + "Open Source Software", + "Security", + "Use Cases", + "Use cases of cryptography" ], - "duration": 544, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "0A4jXL5eBaI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731410400000, - "slot_end": 1731411000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw", - "resources_slides": null, "speakers": [ - "jeff-emmett" - ] + "jean-philippe-bossuat" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731571200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA" }, "vector": [ 0, @@ -530074,7 +530485,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -530550,7 +530960,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -530805,6 +531214,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -530831,12 +531242,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -530882,6 +531293,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -530892,6 +531304,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -530899,6 +531312,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -530911,7 +531328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -530933,7 +531349,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -530946,7 +531361,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -530996,7 +531410,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531032,7 +531445,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531152,7 +531564,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531227,7 +531638,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531369,6 +531779,8 @@ 2, 0, 0, + 0, + 0, 2, 0, 0, @@ -531386,52 +531798,45 @@ }, { "session": { - "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560", - "sourceId": "7AWG3A", - "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560", - "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": true, + "id": "my-mother-will-not-use-it", + "sourceId": "HKKFQX", + "title": "\"My mother will not use it\"", + "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Design", + "featured": false, "doNotRecord": false, "keywords": [ - "Native Account Abstraction", - "RIP-7560", - "EIP-7702" + "Inspiration" ], "tags": [ - "In-protocol Account Abstraction", - "Rollups", - "Account Abstraction", - "eip-7702", - "Account Abstraction", - "In-protocol Account Abstraction", - "Rollups" + "inspiration", + "Design", + "Design Thinking", + "UI/UX" ], "language": "en", "speakers": [ - "alex-forshtat" + "nuno-loureiro" ], "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731564000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY" + "slot_start": 1731559800000, + "slot_end": 1731560400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc" }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -532201,7 +532606,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -532210,7 +532614,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -532223,6 +532626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -532306,6 +532710,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -532378,7 +532784,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -532511,7 +532916,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -532587,6 +532991,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -532725,7 +533130,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -532738,41 +533142,64 @@ 0, 0, 0, + 0, + 0, + 2, + 0, 0 ] }, { "session": { - "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs", - "sourceId": "EAABPS", - "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs", - "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.", - "track": "[CLS] EPF Day", + "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond", + "sourceId": "8CDPFC", + "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond", + "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?", + "track": "Coordination", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Client Development", - "Teku", - "Besu", - "Ephemery" - ], "tags": [ - "Consensus", - "Developer Infrastructure", - "User Experience" + "Collective Intelligence", + "Conviction", + "Consensus Mechanisms", + "Civil Resistance", + "Sustainability", + "Public good", + "Regenerative Applications", + "Design Thinking", + "Civil Resistance", + "Collective Intelligence", + "Consensus Mechanisms", + "Conviction", + "Design Thinking", + "Public good", + "Regenerative Applications", + "Sustainability" ], - "language": "en", - "speakers": [ - "glory-justin" + "keywords": [ + "nope" ], + "duration": 544, + "language": "en", + "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07", + "sources_youtubeId": "0A4jXL5eBaI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731485700000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU" + "slot_start": 1731410400000, + "slot_end": 1731411000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw", + "resources_slides": null, + "speakers": [ + "jeff-emmett" + ] }, "vector": [ 0, @@ -532786,10 +533213,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -533264,22 +533687,9 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -533518,7 +533928,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -533529,7 +533938,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -533642,6 +534050,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533663,6 +534072,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533675,6 +534085,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533726,6 +534137,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533761,6 +534173,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533878,6 +534291,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533952,6 +534366,29 @@ 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, @@ -534068,20 +534505,11 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -534097,45 +534525,46 @@ }, { "session": { - "id": "navigating-developer-liability-in-open-source-code", - "sourceId": "EXNLU9", - "title": "Navigating Developer Liability in Open-Source Code", - "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.", - "track": "Coordination", + "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560", + "sourceId": "7AWG3A", + "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560", + "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, + "expertise": "Expert", + "audience": "Engineering", + "featured": true, "doNotRecord": false, "keywords": [ - "developer", - "liability" + "Native Account Abstraction", + "RIP-7560", + "EIP-7702" ], "tags": [ - "DevEx", - "Open Source Software", - "Regulation", - "developer", - "liability", - "DevEx", - "Open Source Software", - "Regulation" + "In-protocol Account Abstraction", + "Rollups", + "Account Abstraction", + "eip-7702", + "Account Abstraction", + "In-protocol Account Abstraction", + "Rollups" ], "language": "en", "speakers": [ - "eva-wong" + "alex-forshtat" ], "eventId": "devcon-7", - "slot_start": 1731651000000, - "slot_end": 1731652800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU" + "slot_start": 1731562200000, + "slot_end": 1731564000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -534143,7 +534572,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -534620,9 +535048,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -534900,7 +535328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534914,6 +535341,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -534922,6 +535350,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -534968,7 +535397,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534977,7 +535405,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -535045,7 +535472,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -535094,6 +535520,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535224,6 +535651,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535296,7 +535724,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -535432,13 +535859,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 2, + 2, + 0, + 0, 0, 0, 0, @@ -535454,44 +535883,40 @@ }, { "session": { - "id": "navigating-stablecoin-yields-and-risks", - "sourceId": "YT9SMK", - "title": "Navigating Stablecoin Yields and Risks", - "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.", - "track": "Cryptoeconomics", - "type": "Panel", + "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs", + "sourceId": "EAABPS", + "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs", + "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Stablecoin", - "DeFi" + "Client Development", + "Teku", + "Besu", + "Ephemery" ], "tags": [ - "Frameworks", - "Best Practices", - "defi", - "Best Practices", - "Frameworks" + "Consensus", + "Developer Infrastructure", + "User Experience" ], "language": "en", "speakers": [ - "ariah-klages-mundt", - "tammy-yang", - "alessandro-buser", - "colin-platt" + "glory-justin" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE" + "slot_start": 1731484800000, + "slot_end": 1731485700000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU" }, "vector": [ 0, 0, - 6, 0, 0, 0, @@ -535505,6 +535930,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -535978,12 +536404,11 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -536234,6 +536659,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -536243,6 +536670,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -536258,7 +536686,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -536281,6 +536708,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -536332,7 +536761,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -536420,7 +536848,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -536811,37 +537238,41 @@ }, { "session": { - "id": "neuroai-for-ai-safety", - "sourceId": "ANUNJW", - "title": "NeuroAI for AI safety", - "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", + "id": "navigating-developer-liability-in-open-source-code", + "sourceId": "EXNLU9", + "title": "Navigating Developer Liability in Open-Source Code", + "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.", + "track": "Coordination", + "type": "Talk", "expertise": "Intermediate", - "audience": "Academic", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc" + "developer", + "liability" + ], + "tags": [ + "DevEx", + "Open Source Software", + "Regulation", + "developer", + "liability", + "DevEx", + "Open Source Software", + "Regulation" ], - "tags": [], "language": "en", "speakers": [ - "patrick-mineault" + "eva-wong" ], "eventId": "devcon-7", - "slot_start": 1731556680000, - "slot_end": 1731557160000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o" + "slot_start": 1731651000000, + "slot_end": 1731652800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -536853,6 +537284,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -537610,6 +538042,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -537676,6 +538110,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -537684,6 +538119,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -537751,6 +538187,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -538001,6 +538438,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -538142,6 +538580,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -538149,7 +538588,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538158,37 +538596,44 @@ }, { "session": { - "id": "neurotech", - "sourceId": "GMSXUV", - "title": "Neurotech", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", + "id": "navigating-stablecoin-yields-and-risks", + "sourceId": "YT9SMK", + "title": "Navigating Stablecoin Yields and Risks", + "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.", + "track": "Cryptoeconomics", + "type": "Panel", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Stablecoin", + "DeFi" + ], + "tags": [ + "Frameworks", + "Best Practices", + "defi", + "Best Practices", + "Frameworks" + ], "language": "en", - "speakers": [], + "speakers": [ + "ariah-klages-mundt", + "tammy-yang", + "alessandro-buser", + "colin-platt" + ], "eventId": "devcon-7", - "slot_start": 1731555480000, - "slot_end": 1731555960000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM" + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -538677,6 +539122,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -538952,6 +539401,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539025,6 +539475,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539112,6 +539563,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539483,6 +539935,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -539501,41 +539954,33 @@ }, { "session": { - "id": "new-account-types-novel-user-flows-but-what-do-they-look-like-breaking-changes-to-ux-in-a-post-7702-world", - "sourceId": "P9FRCH", - "title": "New account types = novel user flows, but what do they look like? Breaking changes to UX in a post-7702 world", - "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.", - "track": "Usability", - "type": "Talk", + "id": "neuroai-for-ai-safety", + "sourceId": "ANUNJW", + "title": "NeuroAI for AI safety", + "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Design", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "Wallet", - "UX" - ], - "tags": [ - "ux", - "wallet", - "Account Abstraction", - "Design", - "Key Management", - "UI/UX" + "d/acc" ], + "tags": [], "language": "en", "speakers": [ - "gregthegreek", - "cindy" + "patrick-mineault" ], "eventId": "devcon-7", - "slot_start": 1731573000000, - "slot_end": 1731574800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1igvH4fHKFwKho-LbIvoWNBLHx_rza8WlcSOHkION9JE" + "slot_start": 1731556680000, + "slot_end": 1731557160000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o" }, "vector": [ 0, + 6, 0, 0, 0, @@ -539543,7 +539988,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -539600,7 +540044,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -540324,7 +540767,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -540332,7 +540774,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -540416,7 +540857,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -540700,9 +541140,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -540835,7 +541272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -540844,6 +541280,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -540852,42 +541295,39 @@ 0, 2, 0, + 0, + 0, 0 ] }, { "session": { - "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum", - "sourceId": "GHVK8E", - "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum", - "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", + "id": "neurotech", + "sourceId": "GMSXUV", + "title": "Neurotech", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "based rollups", - "sequencing", - "composability" - ], - "tags": [ - "Fragmentation", - "Frameworks", - "Layer 2s" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "mteam" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731642600000, - "slot_end": 1731644400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw" + "slot_start": 1731555480000, + "slot_end": 1731555960000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM" }, "vector": [ + 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -540895,7 +541335,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -541385,7 +541824,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -541669,7 +542107,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -541692,7 +542129,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -541731,7 +542167,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -542188,9 +542623,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -542210,34 +542646,38 @@ }, { "session": { - "id": "non-native-arithmetic-via-crt-codes", - "sourceId": "B7CJU8", - "title": "Non-Native Arithmetic via CRT Codes", - "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.", - "track": "Applied Cryptography", + "id": "new-account-types-novel-user-flows-but-what-do-they-look-like-breaking-changes-to-ux-in-a-post-7702-world", + "sourceId": "P9FRCH", + "title": "New account types = novel user flows, but what do they look like? Breaking changes to UX in a post-7702 world", + "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.", + "track": "Usability", "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Design", "featured": false, "doNotRecord": false, "keywords": [ - "Coding Theory", - "Math" + "Wallet", + "UX" ], "tags": [ - "Cryptography", - "SNARK", - "Zero-Knowledge" + "ux", + "wallet", + "Account Abstraction", + "Design", + "Key Management", + "UI/UX" ], "language": "en", "speakers": [ - "liam-eagen" + "gregthegreek", + "cindy" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA" + "slot_start": 1731573000000, + "slot_end": 1731574800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1igvH4fHKFwKho-LbIvoWNBLHx_rza8WlcSOHkION9JE" }, "vector": [ 0, @@ -542248,8 +542688,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -542307,7 +542745,7 @@ 0, 0, 0, - 0, + 6, 0, 0, 0, @@ -542990,8 +543428,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -543034,6 +543470,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -543041,6 +543478,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -543124,6 +543562,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -543259,7 +543698,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -543408,6 +543846,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -543540,12 +543981,11 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -543556,43 +543996,42 @@ 0, 0, 0, + 2, 0, 0 ] }, { "session": { - "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities", - "sourceId": "BEWPLY", - "title": "Onchain Capital Allocation: From current mechanisms to future possbilities", - "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.", - "track": "Coordination", + "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum", + "sourceId": "GHVK8E", + "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum", + "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.", + "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", - "featured": true, + "audience": "Engineering", + "featured": false, "doNotRecord": false, "keywords": [ - "Mycofi" + "based rollups", + "sequencing", + "composability" ], "tags": [ - "Quadratic Voting", - "Public good", - "Regenerative Applications", - "mycofi", - "Public good", - "Quadratic Voting", - "Regenerative Applications" + "Fragmentation", + "Frameworks", + "Layer 2s" ], "language": "en", "speakers": [ - "kevin-owocki" + "mteam" ], "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731393000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE" + "slot_start": 1731642600000, + "slot_end": 1731644400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw" }, "vector": [ 0, @@ -543602,11 +544041,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -543874,7 +544313,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -544093,6 +544531,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -544377,6 +544816,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -544399,6 +544839,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -544437,12 +544878,13 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -544464,7 +544906,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -544542,7 +544983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -544763,7 +545203,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -544895,8 +545334,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -544912,45 +545351,40 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "onchain-is-the-next-online", - "sourceId": "CXZ7UT", - "title": "Onchain is the next online", - "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.", - "track": "Usability", + "id": "non-native-arithmetic-via-crt-codes", + "sourceId": "B7CJU8", + "title": "Non-Native Arithmetic via CRT Codes", + "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Account Abstraction", - "Layer 2s", - "UX", - "Wallets", - "Developer Tools" + "Coding Theory", + "Math" ], "tags": [ - "Layer 2s", - "Account Abstraction", - "Paymaster", - "creators", - "Account Abstraction", - "Layer 2s" + "Cryptography", + "SNARK", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "jesse-pollak" + "liam-eagen" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ" + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA" }, "vector": [ 0, @@ -544961,10 +545395,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -545705,6 +546138,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -545742,7 +546177,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -545757,7 +546191,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -545975,6 +546408,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -546122,8 +546556,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -546255,10 +546687,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 2, + 0, 2, 0, 0, @@ -546270,49 +546704,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "open-challenges-in-mini-apps-and-frames", - "sourceId": "TZDRPY", - "title": "Open challenges in Mini-apps and Frames", - "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, + "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities", + "sourceId": "BEWPLY", + "title": "Onchain Capital Allocation: From current mechanisms to future possbilities", + "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": true, "doNotRecord": false, - "tags": [ - "Social", - "UI/UX", - "frames", - "Social", - "UI/UX" - ], "keywords": [ - "frames" + "Mycofi" + ], + "tags": [ + "Quadratic Voting", + "Public good", + "Regenerative Applications", + "mycofi", + "Public good", + "Quadratic Voting", + "Regenerative Applications" ], - "duration": 480, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "xoMfU9Gk0xc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731400800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M", - "resources_slides": null, "speakers": [ - "david-furlong" - ] + "kevin-owocki" + ], + "eventId": "devcon-7", + "slot_start": 1731391200000, + "slot_end": 1731393000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE" }, "vector": [ 0, @@ -546323,10 +546751,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -546594,6 +547022,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -546815,7 +547244,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -547112,7 +547540,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -547164,6 +547591,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -547185,6 +547613,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -547233,7 +547662,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -547265,6 +547693,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -547483,10 +547912,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -547615,15 +548044,15 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -547637,31 +548066,42 @@ }, { "session": { - "id": "open-decentralized-ai", - "sourceId": "WDMSDF", - "title": "Open + Decentralized AI", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "onchain-is-the-next-online", + "sourceId": "CXZ7UT", + "title": "Onchain is the next online", + "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.", + "track": "Usability", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Account Abstraction", + "Layer 2s", + "UX", + "Wallets", + "Developer Tools" + ], + "tags": [ + "Layer 2s", + "Account Abstraction", + "Paymaster", + "creators", + "Account Abstraction", + "Layer 2s" + ], "language": "en", - "speakers": [], + "speakers": [ + "jesse-pollak" + ], "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ" }, "vector": [ - 0, - 6, - 0, - 0, 0, 0, 0, @@ -547670,6 +548110,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -548160,6 +548601,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -548450,6 +548892,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -548464,6 +548907,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -548828,6 +549272,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -548962,9 +549408,8 @@ 2, 0, 0, - 2, - 0, 0, + 2, 0, 0, 0, @@ -548980,25 +549425,44 @@ }, { "session": { - "id": "open-source-orchestra-coffee-shop-welcome", - "sourceId": "RKELBQ", - "title": "Open-Source Orchestra coffee shop welcome", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "open-challenges-in-mini-apps-and-frames", + "sourceId": "TZDRPY", + "title": "Open challenges in Mini-apps and Frames", + "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "tags": [ + "Social", + "UI/UX", + "frames", + "Social", + "UI/UX" + ], + "keywords": [ + "frames" + ], + "duration": 480, "language": "en", - "speakers": [], + "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe", + "sources_youtubeId": "xoMfU9Gk0xc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731636000000, - "slot_end": 1731639600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0" + "slot_start": 1731400200000, + "slot_end": 1731400800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M", + "resources_slides": null, + "speakers": [ + "david-furlong" + ] }, "vector": [ 0, @@ -549009,7 +549473,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -549502,6 +549965,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -549799,6 +550263,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -549919,6 +550384,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -550171,7 +550637,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -550305,11 +550771,10 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -550323,36 +550788,39 @@ }, { "session": { - "id": "open-source-orchestra-zukaraoke-ktv", - "sourceId": "JBCULT", - "title": "Open Source Orchestra - ZuKaraoke KTV", - "description": "OSO brings karaoke to Devcon!", - "track": "Entertainment", - "type": "Music", - "expertise": "Beginner", - "audience": "Hobby", + "id": "open-decentralized-ai", + "sourceId": "WDMSDF", + "title": "Open + Decentralized AI", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Music", - "Karaoke" - ], - "tags": [ - "Art", - "Free Speech", - "Social" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "veronica" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q" + "slot_start": 1731579600000, + "slot_end": 1731580200000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs" }, "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -550362,7 +550830,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -550854,7 +551321,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -551118,7 +551584,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -551199,7 +551664,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -551271,12 +551735,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -551653,6 +552111,7 @@ 0, 0, 0, + 2, 0, 0, 2, @@ -551664,8 +552123,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -551675,12 +552132,12 @@ }, { "session": { - "id": "opening-ceremony", - "sourceId": "X3JSYF", - "title": "Opening Ceremony", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", + "id": "open-source-orchestra-coffee-shop-welcome", + "sourceId": "RKELBQ", + "title": "Open-Source Orchestra coffee shop welcome", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", "expertise": "", "audience": "Engineering", "featured": false, @@ -551688,15 +552145,12 @@ "keywords": [], "tags": [], "language": "en", - "speakers": [ - "skylar-weaver" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731380400000, - "slot_end": 1731381300000, - "slot_roomId": "main-stage", - "sources_youtubeId": "dMLeSMcBskU", - "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw" + "slot_start": 1731636000000, + "slot_end": 1731639600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0" }, "vector": [ 0, @@ -551705,10 +552159,12 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -551883,7 +552339,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -553021,25 +553476,34 @@ }, { "session": { - "id": "opening-circle", - "sourceId": "T7THRV", - "title": "Opening Circle", - "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45", + "id": "open-source-orchestra-zukaraoke-ktv", + "sourceId": "JBCULT", + "title": "Open Source Orchestra - ZuKaraoke KTV", + "description": "OSO brings karaoke to Devcon!", "track": "Entertainment", - "type": "Mixed Formats", + "type": "Music", "expertise": "Beginner", "audience": "Hobby", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Music", + "Karaoke" + ], + "tags": [ + "Art", + "Free Speech", + "Social" + ], "language": "en", - "speakers": [], + "speakers": [ + "veronica" + ], "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731397500000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0" + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q" }, "vector": [ 0, @@ -553543,6 +554007,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -553807,6 +554272,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -553887,6 +554353,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -553958,9 +554425,7 @@ 0, 0, 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -554364,54 +554829,37 @@ }, { "session": { - "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt", - "sourceId": "TAEPPF", - "title": "OpSec for the Dark Forest (or how to avoid getting rekt)", - "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "opening-ceremony", + "sourceId": "X3JSYF", + "title": "Opening Ceremony", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Privacy", - "Security", - "Hacks", - "2FA", - "dprk", - "2FA", - "Hacks", - "Privacy", - "Security" - ], - "keywords": [ - "OpSec", - "Social Engineering", - "Malware", - "0days", - "DPRK" - ], - "duration": 542, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "nM2BBNlIRe4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt", - "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731406200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY", - "resources_slides": null, "speakers": [ - "pablo-sabbatella" - ] + "skylar-weaver" + ], + "eventId": "devcon-7", + "slot_start": 1731380400000, + "slot_end": 1731381300000, + "slot_roomId": "main-stage", + "sources_youtubeId": "dMLeSMcBskU", + "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab", + "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -554590,6 +555038,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -554914,7 +555363,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -555150,7 +555598,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -555267,7 +555714,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -555317,7 +555763,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -555401,7 +555846,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -555584,7 +556028,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -555712,8 +556155,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 2, @@ -555734,50 +556177,75 @@ }, { "session": { - "id": "optimism-retro-funding-so-far-so-good-so-what", - "sourceId": "QCMZS8", - "title": "Optimism Retro Funding: So Far, So Good, So What!?", - "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "opening-circle", + "sourceId": "T7THRV", + "title": "Opening Circle", + "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "Beginner", + "audience": "Hobby", "featured": false, "doNotRecord": false, - "tags": [ - "RPGF", - "Collective Intelligence", - "Open Source Software", - "grants", - "Collective Intelligence", - "Open Source Software", - "RPGF" - ], - "keywords": [ - "Data Science", - "Impact Measurement", - "Grants" - ], - "duration": 1542, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "MmjAhdEbnV0", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt", - "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A", - "resources_slides": null, - "speakers": [ - "carl-cervone" - ] + "slot_start": 1731394800000, + "slot_end": 1731397500000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -555789,7 +556257,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -556281,7 +556748,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -556550,7 +557016,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -556614,7 +557079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -556782,47 +557246,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -557083,13 +557506,11 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -557100,40 +557521,55 @@ }, { "session": { - "id": "optimize-zkevm-throughput-series-ii", - "sourceId": "HRDW3R", - "title": "Optimize zkEVM throughput: Series II", - "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Expert", - "audience": "Developer", + "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt", + "sourceId": "TAEPPF", + "title": "OpSec for the Dark Forest (or how to avoid getting rekt)", + "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "L2" - ], "tags": [ - "ZK-EVMs", - "EVM-equivalent", - "ZKP", - "l2", - "EVM-equivalent", - "ZK-EVMs", - "ZKP" + "Privacy", + "Security", + "Hacks", + "2FA", + "dprk", + "2FA", + "Hacks", + "Privacy", + "Security" ], - "language": "en", - "speakers": [ - "ignasi-ramos", - "carlos-matallana" + "keywords": [ + "OpSec", + "Social Engineering", + "Malware", + "0days", + "DPRK" ], + "duration": 542, + "language": "en", + "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c", + "sources_youtubeId": "nM2BBNlIRe4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt", + "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.", "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM" + "slot_start": 1731405600000, + "slot_end": 1731406200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY", + "resources_slides": null, + "speakers": [ + "pablo-sabbatella" + ] }, "vector": [ + 6, 0, 0, 0, @@ -557141,7 +557577,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -557636,10 +558071,9 @@ 0, 0, 0, + 6, 0, 0, - 6, - 6, 0, 0, 0, @@ -557874,6 +558308,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -557947,7 +558382,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -557991,6 +558425,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -558040,6 +558475,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -558124,6 +558560,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -558196,7 +558633,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558220,7 +558656,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558435,12 +558870,13 @@ 0, 0, 0, + 2, + 0, 0, 0, 2, 0, 0, - 2, 0, 0, 0, @@ -558456,47 +558892,54 @@ }, { "session": { - "id": "optimizing-full-node-costs-with-monitor-tools", - "sourceId": "D9UAVG", - "title": "Optimizing full node costs with monitor tools", - "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.", - "track": "Core Protocol", - "type": "Lightning Talk", + "id": "optimism-retro-funding-so-far-so-good-so-what", + "sourceId": "QCMZS8", + "title": "Optimism Retro Funding: So Far, So Good, So What!?", + "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.", + "track": "Coordination", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "performance optimization", - "service level improvement" - ], "tags": [ - "Architecture", - "Developer Infrastructure", - "Best Practices", - "service", - "level", - "improvement", - "Architecture", - "Best Practices", - "Developer Infrastructure" + "RPGF", + "Collective Intelligence", + "Open Source Software", + "grants", + "Collective Intelligence", + "Open Source Software", + "RPGF" ], - "language": "en", - "speakers": [ - "jsvisa" + "keywords": [ + "Data Science", + "Impact Measurement", + "Grants" ], + "duration": 1542, + "language": "en", + "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74", + "sources_youtubeId": "MmjAhdEbnV0", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt", + "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.", "eventId": "devcon-7", - "slot_start": 1731571800000, - "slot_end": 1731572400000, + "slot_start": 1731407400000, + "slot_end": 1731409200000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no" + "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A", + "resources_slides": null, + "speakers": [ + "carl-cervone" + ] }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -558504,6 +558947,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -558921,7 +559365,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -558996,6 +559439,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -559261,11 +559705,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -559284,7 +559729,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -559292,7 +559736,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -559330,6 +559773,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -559498,6 +559942,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -559517,7 +559965,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -559666,8 +560113,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -559796,8 +560241,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -559814,44 +560259,48 @@ }, { "session": { - "id": "oracles-for-number-values", - "sourceId": "DBKAJX", - "title": "Oracles for number values", - "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "optimize-zkevm-throughput-series-ii", + "sourceId": "HRDW3R", + "title": "Optimize zkEVM throughput: Series II", + "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Expert", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Oracles" + "L2" ], "tags": [ - "Mechanism design", - "oracle", - "Mechanism", - "design" + "ZK-EVMs", + "EVM-equivalent", + "ZKP", + "l2", + "EVM-equivalent", + "ZK-EVMs", + "ZKP" ], "language": "en", "speakers": [ - "william-george" + "ignasi-ramos", + "carlos-matallana" ], "eventId": "devcon-7", - "slot_start": 1731659400000, - "slot_end": 1731661200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8" + "slot_start": 1731571200000, + "slot_end": 1731576600000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM" }, "vector": [ 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -560348,9 +560797,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -560589,7 +561039,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -560658,6 +561107,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -560905,6 +561356,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -560928,6 +561380,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -561014,15 +561467,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -561144,9 +561595,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 2, @@ -561160,47 +561611,51 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world", - "sourceId": "USJSPF", - "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world", - "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.", - "track": "Cypherpunk & Privacy", + "id": "optimizing-full-node-costs-with-monitor-tools", + "sourceId": "D9UAVG", + "title": "Optimizing full node costs with monitor tools", + "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.", + "track": "Core Protocol", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "ssi" + "performance optimization", + "service level improvement" ], "tags": [ - "ssi", - "Digital Sovereignty", - "Identity", - "Privacy" + "Architecture", + "Developer Infrastructure", + "Best Practices", + "service", + "level", + "improvement", + "Architecture", + "Best Practices", + "Developer Infrastructure" ], "language": "en", "speakers": [ - "miros" + "jsvisa" ], "eventId": "devcon-7", - "slot_start": 1731494400000, - "slot_end": 1731495000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY" + "slot_start": 1731571800000, + "slot_end": 1731572400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -561626,6 +562081,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -561703,7 +562159,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -561967,6 +562422,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -561983,20 +562439,21 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -562051,7 +562508,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -562223,6 +562679,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562370,12 +562827,13 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -562495,6 +562953,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562505,8 +562964,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -562518,43 +562975,36 @@ }, { "session": { - "id": "panel-source-code-verification", - "sourceId": "UJJPSH", - "title": "Panel: Source Code Verification", - "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability", - "track": "Developer Experience", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", + "id": "oracles-for-number-values", + "sourceId": "DBKAJX", + "title": "Oracles for number values", + "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Source Code Verification", - "Block Explorers" + "Oracles" ], "tags": [ - "Developer Infrastructure", - "User Experience", - "blocks", - "explorer", - "Developer Infrastructure", - "User Experience" + "Mechanism design", + "oracle", + "Mechanism", + "design" ], "language": "en", "speakers": [ - "kirill-fedoseev", - "kaan-uzdogan", - "gary-thung", - "giacomo-barbieri" + "william-george" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731497400000, + "slot_start": 1731659400000, + "slot_end": 1731661200000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0" + "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8" }, "vector": [ - 0, 0, 0, 6, @@ -562604,7 +563054,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -562895,7 +563344,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -563062,7 +563510,7 @@ 0, 0, 0, - 6, + 0, 6, 0, 0, @@ -563303,12 +563751,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -563346,7 +563794,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -563439,7 +563886,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -563734,6 +564180,10 @@ 0, 0, 0, + 0, + 0, + 2, + 2, 2, 0, 0, @@ -563858,10 +564308,12 @@ 0, 2, 0, - 2, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -563876,43 +564328,42 @@ }, { "session": { - "id": "passkeys-the-good-the-bad-the-ugly", - "sourceId": "XFLPAR", - "title": "Passkeys : the good, the bad, the ugly", - "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", + "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world", + "sourceId": "USJSPF", + "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world", + "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "TEE" + "ssi" ], "tags": [ - "Security", - "Account Abstraction", - "TEE", - "Account Abstraction", - "Security" + "ssi", + "Digital Sovereignty", + "Identity", + "Privacy" ], "language": "en", "speakers": [ - "nicolas-bacca" + "miros" ], "eventId": "devcon-7", - "slot_start": 1731482400000, - "slot_end": 1731484200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ" + "slot_start": 1731494400000, + "slot_end": 1731495000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY" }, "vector": [ - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -564414,10 +564865,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -564645,7 +565096,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -564697,6 +565147,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -564763,6 +565214,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -564977,7 +565429,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -565087,6 +565538,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -565207,16 +565659,16 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -565229,46 +565681,42 @@ }, { "session": { - "id": "peerdas-in-grandine", - "sourceId": "YLLNEW", - "title": "PeerDAS in Grandine", - "description": "EPF project presentation on improving PeerDAS implementation in Grandine", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", + "id": "panel-source-code-verification", + "sourceId": "UJJPSH", + "title": "Panel: Source Code Verification", + "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability", + "track": "Developer Experience", + "type": "Panel", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Source Code Verification", + "Block Explorers" + ], "tags": [ - "Core Protocol", - "DAS", - "Data Availability", - "EIP4844" + "Developer Infrastructure", + "User Experience", + "blocks", + "explorer", + "Developer Infrastructure", + "User Experience" ], "language": "en", "speakers": [ - "hangleang" + "kirill-fedoseev", + "kaan-uzdogan", + "gary-thung", + "giacomo-barbieri" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731483900000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE" + "slot_start": 1731493800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -565319,6 +565767,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -565609,6 +566058,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -565768,9 +566218,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -565778,6 +566225,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -566014,7 +566463,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -566024,6 +566472,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -566058,7 +566507,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -566155,6 +566603,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -566350,33 +566799,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, @@ -566476,6 +566898,45 @@ 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, @@ -566579,35 +567040,38 @@ }, { "session": { - "id": "peerdas-metrics-specifications", - "sourceId": "UYPWVK", - "title": "PeerDAS metrics specifications", - "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", + "id": "passkeys-the-good-the-bad-the-ugly", + "sourceId": "XFLPAR", + "title": "Passkeys : the good, the bad, the ugly", + "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness", + "track": "Security", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "DevOps" + "TEE" ], "tags": [ - "Core Protocol", - "Testing", - "Tooling" + "Security", + "Account Abstraction", + "TEE", + "Account Abstraction", + "Security" ], "language": "en", "speakers": [ - "ekaterina-riazantseva" + "nicolas-bacca" ], "eventId": "devcon-7", - "slot_start": 1731483900000, - "slot_end": 1731484800000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ" + "slot_start": 1731482400000, + "slot_end": 1731484200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ" }, "vector": [ + 6, 0, 0, 0, @@ -566623,7 +567087,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -567118,9 +567581,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -567347,6 +567810,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -567365,9 +567830,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -567398,6 +567861,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -567588,7 +568052,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -567679,6 +568142,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -567912,9 +568376,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -567930,39 +568394,32 @@ }, { "session": { - "id": "permissionless-p2p-with-the-waku-network", - "sourceId": "N9WRM3", - "title": "Permissionless P2P with The Waku Network", - "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Intermediate", + "id": "peerdas-in-grandine", + "sourceId": "YLLNEW", + "title": "PeerDAS in Grandine", + "description": "EPF project presentation on improving PeerDAS implementation in Grandine", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "p2p", - "infra" - ], + "keywords": [], "tags": [ - "Developer Infrastructure", - "Privacy", - "DePIN", - "infra", - "p2p", - "DePIN", - "Developer Infrastructure", - "Privacy" + "Core Protocol", + "DAS", + "Data Availability", + "EIP4844" ], "language": "en", "speakers": [ - "sasha" + "hangleang" ], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM" + "slot_start": 1731483000000, + "slot_end": 1731483900000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE" }, "vector": [ 0, @@ -567970,9 +568427,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -567983,6 +568437,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -568757,7 +569212,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -568770,8 +569224,11 @@ 0, 0, 0, + 2, + 0, 0, 0, + 2, 0, 0, 0, @@ -568820,7 +569277,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -569001,7 +569457,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -569061,6 +569516,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -569146,7 +569603,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -569265,10 +569721,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 2, + 0, 2, 0, 0, @@ -569287,34 +569745,33 @@ }, { "session": { - "id": "play-a-massive-onchain-war-game-mud-day-demo", - "sourceId": "PG3VAG", - "title": "Play a massive onchain war game! - MUD Day Demo", - "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "peerdas-metrics-specifications", + "sourceId": "UYPWVK", + "title": "PeerDAS metrics specifications", + "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.", + "track": "[CLS] EPF Day", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Hobby", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "", - "" + "DevOps" ], "tags": [ - "Autonomous World", - "Coordination", - "Gaming" + "Core Protocol", + "Testing", + "Tooling" ], "language": "en", "speakers": [ - "stokarz" + "ekaterina-riazantseva" ], "eventId": "devcon-7", - "slot_start": 1731554700000, - "slot_end": 1731555000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w" + "slot_start": 1731483900000, + "slot_end": 1731484800000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ" }, "vector": [ 0, @@ -569329,12 +569786,10 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -570077,6 +570532,9 @@ 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, @@ -570165,8 +570623,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -570210,7 +570666,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -570301,6 +570756,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -570623,12 +571079,14 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -570639,45 +571097,41 @@ }, { "session": { - "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop", - "sourceId": "QAQAUX", - "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop", - "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.", - "track": "Applied Cryptography", + "id": "permissionless-p2p-with-the-waku-network", + "sourceId": "N9WRM3", + "title": "Permissionless P2P with The Waku Network", + "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.", + "track": "Cypherpunk & Privacy", "type": "Workshop", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "cryptographic primitives", - "implementation" + "p2p", + "infra" ], "tags": [ - "Zk Rollups", - "Zero-Knowledge", - "Cryptography", - "implementation", - "Cryptography", - "Zero-Knowledge", - "Zk Rollups" + "Developer Infrastructure", + "Privacy", + "DePIN", + "infra", + "p2p", + "DePIN", + "Developer Infrastructure", + "Privacy" ], "language": "en", "speakers": [ - "giuseppe" + "sasha" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731650400000, + "slot_start": 1731571200000, + "slot_end": 1731576600000, "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg" + "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM" }, "vector": [ - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -571188,18 +571642,10 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -571423,8 +571869,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -571449,6 +571893,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -571543,6 +571988,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -571724,6 +572170,24 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -571850,11 +572314,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -571973,13 +572432,14 @@ 0, 0, 0, + 0, 2, 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -571995,35 +572455,34 @@ }, { "session": { - "id": "popcraft-mud-day-demo", - "sourceId": "UDJFDV", - "title": "PopCraft - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.", + "id": "play-a-massive-onchain-war-game-mud-day-demo", + "sourceId": "PG3VAG", + "title": "Play a massive onchain war game! - MUD Day Demo", + "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.", "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Beginner", + "audience": "Hobby", "featured": false, "doNotRecord": false, "keywords": [ - "Fully", - "on-chain", - "game" + "", + "" ], "tags": [ "Autonomous World", - "Gaming", - "Not financial" + "Coordination", + "Gaming" ], "language": "en", "speakers": [ - "ck" + "stokarz" ], "eventId": "devcon-7", - "slot_start": 1731557100000, - "slot_end": 1731557400000, + "slot_start": 1731554700000, + "slot_end": 1731555000000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw" + "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w" }, "vector": [ 0, @@ -572540,9 +572999,10 @@ 0, 0, 0, + 6, + 0, 0, 0, - 6, 0, 0, 0, @@ -572919,6 +573379,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573002,7 +573463,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -573326,18 +573786,18 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -573348,27 +573808,38 @@ }, { "session": { - "id": "porting-dark-forest-to-mud-mud-day-demo", - "sourceId": "VBS9CJ", - "title": "Porting Dark Forest to MUD - MUD Day Demo", - "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop", + "sourceId": "QAQAUX", + "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop", + "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.", + "track": "Applied Cryptography", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], + "doNotRecord": true, + "keywords": [ + "cryptographic primitives", + "implementation" + ], + "tags": [ + "Zk Rollups", + "Zero-Knowledge", + "Cryptography", + "implementation", + "Cryptography", + "Zero-Knowledge", + "Zk Rollups" + ], "language": "en", "speakers": [ - "ddy" + "giuseppe" ], "eventId": "devcon-7", - "slot_start": 1731556200000, - "slot_end": 1731556500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4" + "slot_start": 1731645000000, + "slot_end": 1731650400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg" }, "vector": [ 0, @@ -573381,8 +573852,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -574124,6 +574593,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -574179,6 +574650,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -574553,8 +575025,7 @@ 0, 0, 0, - 0, - 0, + 2, 0, 0, 0, @@ -574675,10 +575146,11 @@ 2, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -574693,45 +575165,35 @@ }, { "session": { - "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users", - "sourceId": "X8VZDJ", - "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users", - "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi", - "track": "Usability", + "id": "popcraft-mud-day-demo", + "sourceId": "UDJFDV", + "title": "PopCraft - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "eip-4844", - "Gas", - "Layer 1", - "UI/UX" - ], "keywords": [ - "1559", - "Blobs", - "4844" + "Fully", + "on-chain", + "game" + ], + "tags": [ + "Autonomous World", + "Gaming", + "Not financial" ], - "duration": 434, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "NKGOZ154rPM", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731408000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4", - "resources_slides": null, "speakers": [ - "matt-cutler" - ] + "ck" + ], + "eventId": "devcon-7", + "slot_start": 1731557100000, + "slot_end": 1731557400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw" }, "vector": [ 0, @@ -574742,11 +575204,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -575250,9 +575712,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -575487,7 +575949,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -575531,7 +575992,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -575585,6 +576045,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -575700,7 +576163,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -575712,6 +576174,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -575917,7 +576381,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -576038,12 +576501,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -576056,13 +576519,13 @@ }, { "session": { - "id": "power-centralisation-and-liberal-values", - "sourceId": "EJUTA3", - "title": "Power, Centralisation and Liberal Values", - "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", + "id": "porting-dark-forest-to-mud-mud-day-demo", + "sourceId": "VBS9CJ", + "title": "Porting Dark Forest to MUD - MUD Day Demo", + "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, @@ -576070,15 +576533,21 @@ "tags": [], "language": "en", "speakers": [ - "ahmed-gatnash" + "ddy" ], "eventId": "devcon-7", - "slot_start": 1731651000000, - "slot_end": 1731652200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk" + "slot_start": 1731556200000, + "slot_end": 1731556500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -576590,6 +577059,53 @@ 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, @@ -576598,59 +577114,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -577383,6 +577846,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -577401,43 +577865,56 @@ }, { "session": { - "id": "practical-endgame-on-issuance-policy", - "sourceId": "TQMWK9", - "title": "Practical endgame on issuance policy", - "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.", - "track": "Cryptoeconomics", - "type": "Talk", + "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users", + "sourceId": "X8VZDJ", + "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users", + "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi", + "track": "Usability", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], "tags": [ - "Consensus", - "Economics", - "Staking", - "Tokenomics" + "eip-4844", + "Gas", + "Layer 1", + "UI/UX" ], - "language": "en", - "speakers": [ - "anders-elowsson" + "keywords": [ + "1559", + "Blobs", + "4844" ], + "duration": 434, + "language": "en", + "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107", + "sources_youtubeId": "NKGOZ154rPM", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU" + "slot_start": 1731407400000, + "slot_end": 1731408000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4", + "resources_slides": null, + "speakers": [ + "matt-cutler" + ] }, "vector": [ 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -577947,9 +578424,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -578172,7 +578649,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -578184,6 +578660,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -578202,7 +578680,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -578211,7 +578688,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -578228,6 +578704,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -578296,7 +578773,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -578399,6 +578875,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -578613,6 +579090,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -578733,12 +579211,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -578751,34 +579229,36 @@ }, { "session": { - "id": "prediction-market-panel", - "sourceId": "CCZCSH", - "title": "Prediction market panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", + "id": "power-centralisation-and-liberal-values", + "sourceId": "EJUTA3", + "title": "Power, Centralisation and Liberal Values", + "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], "tags": [], "language": "en", - "speakers": [], + "speakers": [ + "ahmed-gatnash" + ], "eventId": "devcon-7", - "slot_start": 1731563400000, - "slot_end": 1731564300000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k" + "slot_start": 1731651000000, + "slot_end": 1731652200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk" }, "vector": [ 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -579291,6 +579771,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -580073,8 +580554,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 2, 0, @@ -580094,43 +580575,41 @@ }, { "session": { - "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai", - "sourceId": "LKD3RG", - "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI", - "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.", - "track": "Real World Ethereum", - "type": "Lightning Talk", + "id": "practical-endgame-on-issuance-policy", + "sourceId": "TQMWK9", + "title": "Practical endgame on issuance policy", + "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "Federated AI", - "Smart Contracts", - "Transparency" - ], + "keywords": [], "tags": [ - "transparency" + "Consensus", + "Economics", + "Staking", + "Tokenomics" ], "language": "en", "speakers": [ - "sudhir-upadhyay" + "anders-elowsson" ], "eventId": "devcon-7", - "slot_start": 1731564600000, - "slot_end": 1731565200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU" + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -580868,6 +581347,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -580897,6 +581377,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -580905,6 +581386,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -580989,6 +581471,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -581307,8 +581790,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -581428,11 +581909,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -581445,43 +581926,50 @@ }, { "session": { - "id": "privacy-first-cbdcs", - "sourceId": "TWMAWN", - "title": "Privacy-First CBDCs", - "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Lobby", + "id": "prediction-market-panel", + "sourceId": "CCZCSH", + "title": "Prediction market panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "CBDC" - ], - "tags": [ - "Payment", - "Privacy", - "Zero-Knowledge" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "joe-andrews", - "andre-omietanski" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw" + "slot_start": 1731563400000, + "slot_end": 1731564300000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k" }, "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -581702,7 +582190,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -581997,7 +582484,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -582225,7 +582711,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -582330,7 +582815,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -582354,18 +582838,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -582780,6 +583252,7 @@ 2, 0, 0, + 2, 0, 0, 0, @@ -582792,67 +583265,38 @@ 0, 0, 0, - 2 + 0 ] }, { "session": { - "id": "privacy-preserving-groups", - "sourceId": "LSA3JK", - "title": "Privacy-Preserving Groups", - "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.", - "track": "Applied Cryptography", + "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai", + "sourceId": "LKD3RG", + "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI", + "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.", + "track": "Real World Ethereum", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "Tooling", - "DAO", - "Privacy", - "Anonymity", - "Identity", - "Open Source Software", - "ZKP", - "Zero-Knowledge", - "Use cases of cryptography", - "Public good", - "User Experience", - "groups", - "Anonymity", - "DAO", - "Identity", - "Open Source Software", - "Privacy", - "Public good", - "Tooling", - "Use cases of cryptography", - "User Experience", - "Zero-Knowledge", - "ZKP" - ], "keywords": [ - "Groups" + "Federated AI", + "Smart Contracts", + "Transparency" + ], + "tags": [ + "transparency" ], - "duration": 464, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "dWQWoqJVfn8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt", - "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya", + "speakers": [ + "sudhir-upadhyay" + ], "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731397200000, + "slot_start": 1731564600000, + "slot_end": 1731565200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM", - "resources_slides": null, - "speakers": [ - "vivian-plasencia" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU" }, "vector": [ 0, @@ -582861,11 +583305,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -583376,9 +583820,10 @@ 0, 0, 0, + 6, + 0, 0, 0, - 6, 0, 0, 0, @@ -583605,23 +584050,18 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -583642,7 +584082,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -583668,7 +584107,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -583691,10 +584129,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -583702,7 +584138,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -583710,7 +584145,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -584040,7 +584474,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -584051,6 +584484,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -584157,13 +584599,16 @@ 0, 0, 0, - 2, 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -584177,47 +584622,44 @@ }, { "session": { - "id": "prize-worthy-an-ethereum-python-hackathon-guide", - "sourceId": "73J9ZG", - "title": "Prize-Worthy: An Ethereum Python Hackathon Guide", - "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.", - "track": "Developer Experience", - "type": "Workshop", + "id": "privacy-first-cbdcs", + "sourceId": "TWMAWN", + "title": "Privacy-First CBDCs", + "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.", + "track": "Real World Ethereum", + "type": "Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Lobby", "featured": false, "doNotRecord": false, "keywords": [ - "Vyper", - "Solidity" + "CBDC" ], "tags": [ - "Tooling", - "DevEx", - "Open Source Software", - "solidity", - "DevEx", - "Open Source Software", - "Tooling" + "Payment", + "Privacy", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "marc-garreau" + "joe-andrews", + "andre-omietanski" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -584437,6 +584879,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -584731,11 +585174,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -584960,6 +585403,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -584970,7 +585414,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -584979,7 +585422,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585047,7 +585489,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585067,6 +585508,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -585090,6 +585532,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -585313,7 +585756,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585517,7 +585959,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585528,38 +585969,68 @@ 0, 0, 0, - 0 + 0, + 2 ] }, { "session": { - "id": "product-led-blockchain-development", - "sourceId": "8YS9LW", - "title": "Product-Led Blockchain Development", - "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.", - "track": "Usability", + "id": "privacy-preserving-groups", + "sourceId": "LSA3JK", + "title": "Privacy-Preserving Groups", + "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.", + "track": "Applied Cryptography", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "usability", - "product development" - ], "tags": [ - "development", - "product" + "Tooling", + "DAO", + "Privacy", + "Anonymity", + "Identity", + "Open Source Software", + "ZKP", + "Zero-Knowledge", + "Use cases of cryptography", + "Public good", + "User Experience", + "groups", + "Anonymity", + "DAO", + "Identity", + "Open Source Software", + "Privacy", + "Public good", + "Tooling", + "Use cases of cryptography", + "User Experience", + "Zero-Knowledge", + "ZKP" ], - "language": "en", - "speakers": [ - "gregory-rocco" + "keywords": [ + "Groups" ], + "duration": 464, + "language": "en", + "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8", + "sources_youtubeId": "dWQWoqJVfn8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt", + "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya", "eventId": "devcon-7", - "slot_start": 1731552900000, - "slot_end": 1731553500000, + "slot_start": 1731396600000, + "slot_end": 1731397200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck" + "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM", + "resources_slides": null, + "speakers": [ + "vivian-plasencia" + ] }, "vector": [ 0, @@ -585570,11 +586041,9 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -586315,18 +586784,23 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -586347,6 +586821,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -586372,6 +586847,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -586394,8 +586870,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -586403,6 +586881,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -586410,6 +586889,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -586570,14 +587050,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -586697,7 +587169,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -586748,6 +587219,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -586866,11 +587338,11 @@ 0, 2, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -586884,36 +587356,42 @@ }, { "session": { - "id": "programmable-cryptography-and-dacc", - "sourceId": "PNA8NU", - "title": "Programmable Cryptography and d/acc", - "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "prize-worthy-an-ethereum-python-hackathon-guide", + "sourceId": "73J9ZG", + "title": "Prize-Worthy: An Ethereum Python Hackathon Guide", + "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc", - "programmable cryptography" + "Vyper", + "Solidity" ], "tags": [ - "Cryptography", - "Use cases of cryptography" + "Tooling", + "DevEx", + "Open Source Software", + "solidity", + "DevEx", + "Open Source Software", + "Tooling" ], "language": "en", "speakers": [ - "wei-dai", - "muthu-venkitasubramaniam" + "marc-garreau" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ" + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE" }, "vector": [ + 0, + 0, 0, 6, 0, @@ -587337,7 +587815,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -587437,10 +587914,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -587665,7 +588142,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -587674,15 +588150,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -587750,6 +588227,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -588015,6 +588493,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -588218,7 +588697,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -588230,45 +588708,38 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "programmable-cryptography-and-ethereum-panel", - "sourceId": "MWKMBQ", - "title": "Programmable Cryptography and Ethereum, Panel", - "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''", - "track": "Applied Cryptography", - "type": "Panel", + "id": "product-led-blockchain-development", + "sourceId": "8YS9LW", + "title": "Product-Led Blockchain Development", + "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.", + "track": "Usability", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Programmable Cryptography", - "ZKP", - "MPC", - "FHE", - "ORAM", - "Obfuscation", - "Panel", - "0xPARC" + "usability", + "product development" + ], + "tags": [ + "development", + "product" ], - "tags": [], "language": "en", "speakers": [ - "gubsheep", - "albert-ni", - "barry-whitehat", - "vitalik-buterin" + "gregory-rocco" ], "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731403800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU" + "slot_start": 1731552900000, + "slot_end": 1731553500000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck" }, "vector": [ 0, @@ -588279,9 +588750,11 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, - 6, 0, 0, 0, @@ -588458,14 +588931,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -588698,7 +589168,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -588798,6 +589267,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -589282,6 +589752,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589407,6 +589878,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589575,11 +590047,11 @@ 0, 2, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -589593,41 +590065,36 @@ }, { "session": { - "id": "programmable-cryptography-and-smart-contract", - "sourceId": "VJEDLX", - "title": "Programmable Cryptography and Smart Contract", - "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.", - "track": "Developer Experience", + "id": "programmable-cryptography-and-dacc", + "sourceId": "PNA8NU", + "title": "Programmable Cryptography and d/acc", + "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Programable", - "Cryptography" + "d/acc", + "programmable cryptography" ], "tags": [ - "DevEx", "Cryptography", - "MPC", - "programmable", - "DevEx", - "MPC" + "Use cases of cryptography" ], "language": "en", "speakers": [ - "shouki-tsuda" + "wei-dai", + "muthu-venkitasubramaniam" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731472800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI" + "slot_start": 1731577800000, + "slot_end": 1731579000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ" }, "vector": [ - 0, - 0, 0, 6, 0, @@ -590051,6 +590518,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -590377,9 +590845,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -590453,7 +590921,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -590812,7 +591279,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -590928,13 +591394,17 @@ 0, 0, 0, - 2, + 0, 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -590948,38 +591418,39 @@ }, { "session": { - "id": "programmable-cryptography-and-the-future-of-the-internet", - "sourceId": "JVGEDS", - "title": "Programmable Cryptography and the future of the Internet", - "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.", + "id": "programmable-cryptography-and-ethereum-panel", + "sourceId": "MWKMBQ", + "title": "Programmable Cryptography and Ethereum, Panel", + "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''", "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", + "type": "Panel", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [], "keywords": [ - "None" + "Programmable Cryptography", + "ZKP", + "MPC", + "FHE", + "ORAM", + "Obfuscation", + "Panel", + "0xPARC" ], - "duration": 3349, + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "PSs8d_ZzFCk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "gubsheep", + "albert-ni", + "barry-whitehat", + "vitalik-buterin" + ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731467700000, + "slot_start": 1731400200000, + "slot_end": 1731403800000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", - "resources_slides": null, - "speakers": [ - "justin-glibert" - ] + "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU" }, "vector": [ 0, @@ -591168,13 +591639,15 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -591407,6 +591880,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -592284,8 +592758,6 @@ 0, 2, 0, - 0, - 0, 2, 0, 0, @@ -592304,41 +592776,44 @@ }, { "session": { - "id": "programmable-cryptography-from-a-software-engineering-lens", - "sourceId": "SWD9LD", - "title": "Programmable Cryptography from a Software Engineering Lens", - "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "", + "id": "programmable-cryptography-and-smart-contract", + "sourceId": "VJEDLX", + "title": "Programmable Cryptography and Smart Contract", + "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Programmable", + "Programable", "Cryptography" ], "tags": [ - "Cryptography" + "DevEx", + "Cryptography", + "MPC", + "programmable", + "DevEx", + "MPC" ], "language": "en", "speakers": [ - "aayush-gupta", - "justin-glibert", - "arnaucube", - "ahmad", - "kevin-kwok" + "shouki-tsuda" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731654000000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg" + "slot_start": 1731472200000, + "slot_end": 1731472800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI" }, "vector": [ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -592350,7 +592825,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -592358,7 +592832,6 @@ 0, 0, 0, - 4, 0, 0, 0, @@ -592451,7 +592924,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -592522,7 +592994,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -592603,7 +593074,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -592864,9 +593334,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -593087,11 +593557,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -593108,6 +593578,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -593166,6 +593637,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -593524,6 +593996,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -593636,10 +594109,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, @@ -593650,7 +594125,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -593658,27 +594132,38 @@ }, { "session": { - "id": "project-mirage-mud-day-demo", - "sourceId": "BVANRC", - "title": "Project Mirage - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", + "id": "programmable-cryptography-and-the-future-of-the-internet", + "sourceId": "JVGEDS", + "title": "Programmable Cryptography and the future of the Internet", + "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], "tags": [], - "language": "en", - "speakers": [ - "y77cao" + "keywords": [ + "None" ], + "duration": 3349, + "language": "en", + "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c", + "sources_youtubeId": "", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731557400000, - "slot_end": 1731557700000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M" + "slot_start": 1731465900000, + "slot_end": 1731467700000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", + "resources_slides": null, + "speakers": [ + "justin-glibert" + ] }, "vector": [ 0, @@ -593691,9 +594176,10 @@ 0, 0, 0, + 6, + 0, 0, 0, - 6, 0, 0, 0, @@ -593866,6 +594352,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -594029,7 +594516,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -595003,34 +595489,38 @@ }, { "session": { - "id": "proof-of-personhood-panel", - "sourceId": "GVML7H", - "title": "Proof of personhood panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "programmable-cryptography-from-a-software-engineering-lens", + "sourceId": "SWD9LD", + "title": "Programmable Cryptography from a Software Engineering Lens", + "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Programmable", + "Cryptography" + ], + "tags": [ + "Cryptography" + ], "language": "en", - "speakers": [], + "speakers": [ + "aayush-gupta", + "justin-glibert", + "arnaucube", + "ahmad", + "kevin-kwok" + ], "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731561000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM" + "slot_start": 1731648600000, + "slot_end": 1731654000000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -595045,6 +595535,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -595052,6 +595543,7 @@ 0, 0, 0, + 4, 0, 0, 0, @@ -595144,6 +595636,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -595214,6 +595707,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -595294,6 +595788,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -595554,6 +596049,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -595777,6 +596273,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -596328,7 +596825,6 @@ 2, 0, 0, - 2, 0, 0, 0, @@ -596340,51 +596836,41 @@ 0, 0, 0, + 2, + 0, 0, 0 ] }, { "session": { - "id": "protec-and-attac-programmatic-execution-layer-consensus-tests", - "sourceId": "GZBP8A", - "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests", - "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.", - "track": "Core Protocol", - "type": "Talk", + "id": "project-mirage-mud-day-demo", + "sourceId": "BVANRC", + "title": "Project Mirage - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Python", - "pytest" - ], - "tags": [ - "Core Protocol", - "EVM-equivalent", - "Testing", - "pytest", - "Core Protocol", - "EVM-equivalent", - "Testing" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "danceratopz" + "y77cao" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0" + "slot_start": 1731557400000, + "slot_end": 1731557700000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -596393,6 +596879,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -596726,6 +597215,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -596790,7 +597283,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -597137,7 +597629,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -597360,7 +597851,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -597442,7 +597932,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -597498,7 +597987,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -597702,39 +598190,29 @@ }, { "session": { - "id": "protocol-alignment-governing-like-a-protocol", - "sourceId": "JDKAJD", - "title": "Protocol Alignment: Governing like a Protocol", - "description": "We define a protocol as *aligned* when **all stakeholders in its network agree**:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.", - "track": "Coordination", + "id": "proof-of-personhood-panel", + "sourceId": "GVML7H", + "title": "Proof of personhood panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "n/a" - ], - "tags": [ - "Governance", - "Futarchy", - "Mechanism design", - "Futarchy", - "Governance", - "Mechanism design" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "noturhandle" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731490800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps" + "slot_start": 1731559800000, + "slot_end": 1731561000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM" }, "vector": [ 0, + 6, 0, 0, 0, @@ -597745,7 +598223,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -598263,7 +598740,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -598479,7 +598955,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -598505,7 +598980,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -598568,7 +599042,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -599034,11 +599507,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -599051,41 +599528,44 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "protocol-guild-a-commons-funding-protocol", - "sourceId": "EJVT7E", - "title": "Protocol Guild: A commons funding protocol", - "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.", + "id": "protec-and-attac-programmatic-execution-layer-consensus-tests", + "sourceId": "GZBP8A", + "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests", + "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.", "track": "Core Protocol", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "ACD", - "Core Protocol", - "DAO", - "Onchain Organization", - "Game Theory" + "Python", + "pytest" ], "tags": [ - "Gaming", - "theory" + "Core Protocol", + "EVM-equivalent", + "Testing", + "pytest", + "Core Protocol", + "EVM-equivalent", + "Testing" ], "language": "en", "speakers": [ - "trent-van-epps" + "danceratopz" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko" + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0" }, "vector": [ 0, @@ -599498,6 +599978,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -599618,7 +600099,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -599846,6 +600326,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -599937,7 +600418,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600070,6 +600550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -600150,6 +600631,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -600205,6 +600687,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -600275,7 +600758,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600387,6 +600869,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -600397,8 +600880,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -600410,38 +600891,38 @@ }, { "session": { - "id": "proving-liquidity-of-an-amm", - "sourceId": "AD3X38", - "title": "Proving liquidity of an AMM", - "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.", - "track": "Security", + "id": "protocol-alignment-governing-like-a-protocol", + "sourceId": "JDKAJD", + "title": "Protocol Alignment: Governing like a Protocol", + "description": "We define a protocol as *aligned* when **all stakeholders in its network agree**:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Invariants" + "n/a" ], "tags": [ - "Formal Verification", - "Reentrancy", - "invariants", - "Formal Verification", - "Reentrancy" + "Governance", + "Futarchy", + "Mechanism design", + "Futarchy", + "Governance", + "Mechanism design" ], "language": "en", "speakers": [ - "jochen-hoenicke" + "noturhandle" ], "eventId": "devcon-7", - "slot_start": 1731471000000, - "slot_end": 1731471600000, + "slot_start": 1731490200000, + "slot_end": 1731490800000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8" + "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps" }, "vector": [ - 6, 0, 0, 0, @@ -600453,6 +600934,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -600970,9 +601452,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -601187,6 +601669,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -601212,6 +601695,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -601274,6 +601758,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -601376,7 +601861,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -601629,8 +602113,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -601741,8 +602223,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -601758,63 +602240,52 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "public-private-hybrid-rollups", - "sourceId": "YUFEJK", - "title": "Public-Private Hybrid Rollups", - "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.", - "track": "Layer 2", + "id": "protocol-guild-a-commons-funding-protocol", + "sourceId": "EJVT7E", + "title": "Protocol Guild: A commons funding protocol", + "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Zk Rollups", - "Token bridging", - "Privacy", - "best", - "practice", - "Privacy", - "Token bridging", - "Zk Rollups" - ], "keywords": [ - "hybrid rollups", - "privacy as a best practice" + "ACD", + "Core Protocol", + "DAO", + "Onchain Organization", + "Game Theory" + ], + "tags": [ + "Gaming", + "theory" ], - "duration": 1396, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "0mDlVkzde_M", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4", - "resources_slides": null, "speakers": [ - "adam-domurad" - ] + "trent-van-epps" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -602337,9 +602808,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -602614,7 +603085,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -602658,11 +603128,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -602748,7 +603218,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -603107,7 +603576,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -603118,6 +603588,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -603129,41 +603601,38 @@ }, { "session": { - "id": "putting-intents-and-users-together", - "sourceId": "YUPJGZ", - "title": "Putting Intents and Users Together", - "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.", - "track": "Usability", + "id": "proving-liquidity-of-an-amm", + "sourceId": "AD3X38", + "title": "Proving liquidity of an AMM", + "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.", + "track": "Security", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Chain", - "Abstraction" + "Invariants" ], "tags": [ - "Rollups", - "Account Abstraction", - "Intents", - "chain", - "abstraction", - "Account Abstraction", - "Intents", - "Rollups" + "Formal Verification", + "Reentrancy", + "invariants", + "Formal Verification", + "Reentrancy" ], "language": "en", "speakers": [ - "abhimanyu-shekhawat" + "jochen-hoenicke" ], "eventId": "devcon-7", - "slot_start": 1731557400000, - "slot_end": 1731558000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc" + "slot_start": 1731471000000, + "slot_end": 1731471600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8" }, "vector": [ + 6, 0, 0, 0, @@ -603172,7 +603641,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -603695,9 +604163,11 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, - 6, 0, 0, 0, @@ -603944,7 +604414,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -603953,11 +604422,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -604104,7 +604571,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -604355,6 +604821,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -604468,9 +604937,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -604486,42 +604955,48 @@ }, { "session": { - "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction", - "sourceId": "QXCTMB", - "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction", - "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.", - "track": "Real World Ethereum", + "id": "public-private-hybrid-rollups", + "sourceId": "YUFEJK", + "title": "Public-Private Hybrid Rollups", + "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Sovereign" - ], "tags": [ - "2FA", - "Account Abstraction", - "Identity", - "Open Source Software", - "Political systems", - "Politics", - "Public good", - "Use Cases", - "Validiums", - "Zero-Knowledge", - "ZK-EVMs", - "ZKP" + "Zk Rollups", + "Token bridging", + "Privacy", + "best", + "practice", + "Privacy", + "Token bridging", + "Zk Rollups" ], - "language": "en", - "speakers": [ - "diego-fernandez" + "keywords": [ + "hybrid rollups", + "privacy as a best practice" ], + "duration": 1396, + "language": "en", + "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e", + "sources_youtubeId": "0mDlVkzde_M", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4", + "resources_slides": null, + "speakers": [ + "adam-domurad" + ] }, "vector": [ 0, @@ -604530,6 +605005,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -605055,10 +605531,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -605274,7 +605750,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -605311,9 +605786,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -605334,14 +605807,13 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -605360,7 +605832,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605368,10 +605839,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -605386,6 +605855,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -605429,7 +605899,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605474,6 +605943,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -605597,7 +606067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605610,7 +606079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605715,7 +606183,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605723,6 +606190,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -605826,7 +606295,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605836,6 +606304,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -605846,34 +606322,41 @@ }, { "session": { - "id": "reading-before-writing-an-approach-to-brain-interfaces", - "sourceId": "AECBRW", - "title": "Reading Before Writing: An Approach to Brain Interfaces", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "putting-intents-and-users-together", + "sourceId": "YUPJGZ", + "title": "Putting Intents and Users Together", + "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.", + "track": "Usability", "type": "Lightning Talk", - "expertise": "", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Chain", + "Abstraction" + ], + "tags": [ + "Rollups", + "Account Abstraction", + "Intents", + "chain", + "abstraction", + "Account Abstraction", + "Intents", + "Rollups" + ], "language": "en", - "speakers": [], + "speakers": [ + "abhimanyu-shekhawat" + ], "eventId": "devcon-7", - "slot_start": 1731557160000, - "slot_end": 1731557580000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c" + "slot_start": 1731557400000, + "slot_end": 1731558000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -605882,6 +606365,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -606406,6 +606890,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -606653,6 +607138,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -606661,9 +607147,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -606811,6 +607299,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -607171,6 +607661,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -607189,50 +607680,51 @@ }, { "session": { - "id": "reading-ethereums-tea-leaves-with-xatu-data", - "sourceId": "LGXA3Q", - "title": "Reading Ethereum's Tea Leaves with Xatu data", - "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.", - "track": "Core Protocol", - "type": "Workshop", + "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction", + "sourceId": "QXCTMB", + "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction", + "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.", + "track": "Real World Ethereum", + "type": "Talk", "expertise": "Beginner", - "audience": "Research", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Data", - "Analysis", - "Observability" + "Sovereign" ], "tags": [ - "Layer 1", - "Consensus", - "Testing", - "observability", - "Consensus", - "Layer 1", - "Testing" + "2FA", + "Account Abstraction", + "Identity", + "Open Source Software", + "Political systems", + "Politics", + "Public good", + "Use Cases", + "Validiums", + "Zero-Knowledge", + "ZK-EVMs", + "ZKP" ], "language": "en", "speakers": [ - "andrew-davis", - "sam-calder-mason" + "diego-fernandez" ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731560400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM" + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -607761,9 +608253,6 @@ 0, 0, 6, - 6, - 0, - 0, 0, 0, 0, @@ -607968,24 +608457,19 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -608022,7 +608506,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -608046,9 +608532,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -608067,6 +608555,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -608074,8 +608563,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -608133,6 +608624,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -608205,7 +608697,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -608301,6 +608792,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -608313,6 +608805,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -608527,13 +609020,14 @@ 0, 0, 0, + 0, 2, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -608547,43 +609041,87 @@ }, { "session": { - "id": "realigning-with-ethereum-from-l1-to-l2", - "sourceId": "PSSQCK", - "title": "(Re)aligning with Ethereum: From L1 to L2", - "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.", - "track": "Layer 2", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Product", + "id": "reading-before-writing-an-approach-to-brain-interfaces", + "sourceId": "AECBRW", + "title": "Reading Before Writing: An Approach to Brain Interfaces", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, - "doNotRecord": true, - "keywords": [ - "Transition", - "Ethereum Allignment", - "EVM" - ], - "tags": [ - "Layer 1", - "Layer 2s", - "Values", - "EVM", - "Layer 1", - "Layer 2s", - "Values" - ], + "doNotRecord": false, + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "justin-drake", - "marek-olszewski", - "david-hoffman" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM" + "slot_start": 1731557160000, + "slot_end": 1731557580000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c" }, "vector": [ + 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, @@ -608591,7 +609129,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -609019,7 +609556,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -609121,8 +609657,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -609337,7 +609871,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -609388,7 +609921,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -609434,7 +609966,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -609529,7 +610060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -609834,8 +610364,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -609848,10 +610380,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "reading-ethereums-tea-leaves-with-xatu-data", + "sourceId": "LGXA3Q", + "title": "Reading Ethereum's Tea Leaves with Xatu data", + "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Data", + "Analysis", + "Observability" + ], + "tags": [ + "Layer 1", + "Consensus", + "Testing", + "observability", + "Consensus", + "Layer 1", + "Testing" + ], + "language": "en", + "speakers": [ + "andrew-davis", + "sam-calder-mason" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731560400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -609884,7 +610458,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -609892,7 +610465,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -609901,52 +610473,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost", - "sourceId": "YRTHKH", - "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost", - "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Preconfirmations" - ], - "tags": [ - "Architecture", - "Protocol Design", - "Scalability", - "Appchains", - "Decentralization", - "User Experience", - "MEV", - "pre-confirmations", - "Appchains", - "Architecture", - "Decentralization", - "MEV", - "Protocol Design", - "Scalability", - "User Experience" - ], - "language": "en", - "speakers": [ - "daniel-marzec" - ], - "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw" - }, - "vector": [ 0, 0, 0, @@ -609954,7 +610480,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -610431,6 +610956,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -610486,7 +611013,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -610639,6 +611165,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -610648,6 +611175,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -610687,7 +611215,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -610701,7 +611228,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -610731,7 +611257,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -610747,7 +611272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -610787,7 +611311,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -610799,7 +611322,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -610825,7 +611347,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -610882,6 +611403,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -611014,7 +611536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -611093,6 +611614,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -611202,8 +611724,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -611215,6 +611739,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "realigning-with-ethereum-from-l1-to-l2", + "sourceId": "PSSQCK", + "title": "(Re)aligning with Ethereum: From L1 to L2", + "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.", + "track": "Layer 2", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": true, + "keywords": [ + "Transition", + "Ethereum Allignment", + "EVM" + ], + "tags": [ + "Layer 1", + "Layer 2s", + "Values", + "EVM", + "Layer 1", + "Layer 2s", + "Values" + ], + "language": "en", + "speakers": [ + "justin-drake", + "marek-olszewski", + "david-hoffman" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM" + }, + "vector": [ 0, 0, 0, @@ -611222,6 +611788,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -611247,11 +611814,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -611264,44 +611829,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits", - "sourceId": "UCFEEN", - "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits", - "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Stablecoins" - ], - "tags": [ - "Decentralization Improvements", - "Censorship Resistance", - "Open Source Software", - "stablecoin", - "Censorship Resistance", - "Decentralization Improvements", - "Open Source Software" - ], - "language": "en", - "speakers": [ - "garm" - ], - "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731582600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g" - }, - "vector": [ 0, 0, 0, @@ -611313,7 +611840,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -611690,6 +612216,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -611791,6 +612318,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -611842,7 +612371,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -612007,6 +612535,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -612046,7 +612575,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -612058,6 +612586,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -612103,6 +612632,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -612138,7 +612668,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -612188,7 +612717,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -612201,6 +612729,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -612495,7 +613024,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -612554,12 +613082,15 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -612568,6 +613099,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost", + "sourceId": "YRTHKH", + "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost", + "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Preconfirmations" + ], + "tags": [ + "Architecture", + "Protocol Design", + "Scalability", + "Appchains", + "Decentralization", + "User Experience", + "MEV", + "pre-confirmations", + "Appchains", + "Architecture", + "Decentralization", + "MEV", + "Protocol Design", + "Scalability", + "User Experience" + ], + "language": "en", + "speakers": [ + "daniel-marzec" + ], + "eventId": "devcon-7", + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw" + }, + "vector": [ 0, 0, 0, @@ -612575,6 +613152,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -612604,103 +613182,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "redefined-interactions-transforming-user-experience-with-intents", - "sourceId": "Q3SF8Q", - "title": "Redefined Interactions: Transforming User Experience with Intents", - "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.", - "track": "Usability", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "tags": [ - "User Experience", - "Intents", - "defi", - "Intents", - "User Experience" - ], - "keywords": [ - "DeFi" - ], - "duration": 2896, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "hId-FQUOpJ0", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731406200000, - "slot_end": 1731409800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU", - "resources_slides": null, - "speakers": [ - "agustin-grosso", - "dominik-hell", - "juli-corti", - "ran-hammer", - "shawn-odonaghue" - ] - }, - "vector": [ - 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, @@ -613203,17 +613684,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -613409,6 +613886,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -613452,6 +613930,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613461,17 +613940,13 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -613511,6 +613986,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613522,6 +613998,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613547,6 +614024,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613599,7 +614077,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -613736,6 +614213,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613972,11 +614450,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -613990,28 +614468,37 @@ }, { "session": { - "id": "redefining-boundaries-in-the-infinite-garden", - "sourceId": "FUZDNX", - "title": "Redefining boundaries in the Infinite Garden", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", + "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits", + "sourceId": "UCFEEN", + "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits", + "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Stablecoins" + ], + "tags": [ + "Decentralization Improvements", + "Censorship Resistance", + "Open Source Software", + "stablecoin", + "Censorship Resistance", + "Decentralization Improvements", + "Open Source Software" + ], "language": "en", "speakers": [ - "aya-miyaguchi" + "garm" ], "eventId": "devcon-7", - "slot_start": 1731382800000, - "slot_end": 1731384000000, - "slot_roomId": "main-stage", - "sources_youtubeId": "SE15rsPVHz0", - "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M" + "slot_start": 1731582000000, + "slot_end": 1731582600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g" }, "vector": [ 0, @@ -614020,14 +614507,12 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -614199,7 +614684,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -614557,6 +615041,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -614761,6 +615246,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -614852,6 +615338,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -614901,6 +615388,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615207,6 +615695,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615330,48 +615819,53 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "redefining-daos-state-of-daos-in-asia", - "sourceId": "PUMYRH", - "title": "Redefining DAOs: State of DAOs in Asia", - "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.", - "track": "Coordination", + "id": "redefined-interactions-transforming-user-experience-with-intents", + "sourceId": "Q3SF8Q", + "title": "Redefined Interactions: Transforming User Experience with Intents", + "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.", + "track": "Usability", "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Standards", - "Asia" - ], "tags": [ - "Coordination", - "DAO", - "Governance", - "asia", - "Coordination", - "DAO", - "Governance" + "User Experience", + "Intents", + "defi", + "Intents", + "User Experience" ], - "language": "en", - "speakers": [ - "joseph-low", - "hazel-devjani", - "gen", - "yvonne", - "vivian-chen" + "keywords": [ + "DeFi" ], + "duration": 2896, + "language": "en", + "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94", + "sources_youtubeId": "hId-FQUOpJ0", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731475800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE" + "slot_start": 1731406200000, + "slot_end": 1731409800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU", + "resources_slides": null, + "speakers": [ + "agustin-grosso", + "juli-corti", + "ran-hammer", + "dominik-hell", + "shawn-odonaghue" + ] }, "vector": [ 0, @@ -615382,9 +615876,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -615918,8 +616409,6 @@ 0, 0, 0, - 0, - 0, 6, 6, 6, @@ -616134,6 +616623,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -616172,6 +616662,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -616208,12 +616705,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -616267,7 +616762,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -616306,6 +616800,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -616568,8 +617070,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -616669,6 +617169,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -616683,12 +617184,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0 @@ -616696,44 +617191,37 @@ }, { "session": { - "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution", - "sourceId": "FKVE9X", - "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution", - "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Expert", + "id": "redefining-boundaries-in-the-infinite-garden", + "sourceId": "FUZDNX", + "title": "Redefining boundaries in the Infinite Garden", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "RPC", - "Execution" - ], - "tags": [ - "Scalability", - "EVM-equivalent", - "Tooling", - "execution", - "EVM-equivalent", - "Scalability", - "Tooling" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "everton-fraga" + "aya-miyaguchi" ], "eventId": "devcon-7", - "slot_start": 1731565200000, - "slot_end": 1731565800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw" + "slot_start": 1731382800000, + "slot_end": 1731384000000, + "slot_roomId": "main-stage", + "sources_youtubeId": "SE15rsPVHz0", + "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0", + "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M" }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -616913,6 +617401,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -617281,7 +617771,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -617489,7 +617978,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -617608,7 +618096,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -617663,7 +618150,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -617792,7 +618278,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -618034,6 +618519,8 @@ 0, 0, 2, + 0, + 0, 2, 0, 0, @@ -618052,50 +618539,42 @@ }, { "session": { - "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies", - "sourceId": "JPHQYQ", - "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies", - "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.", - "track": "Real World Ethereum", - "type": "Talk", + "id": "redefining-daos-state-of-daos-in-asia", + "sourceId": "PUMYRH", + "title": "Redefining DAOs: State of DAOs in Asia", + "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.", + "track": "Coordination", + "type": "Panel", "expertise": "Beginner", - "audience": "Academic", + "audience": "Community", "featured": false, "doNotRecord": false, + "keywords": [ + "Standards", + "Asia" + ], "tags": [ "Coordination", - "Political systems", - "Solarpunk", - "Regenative Ethereum", - "value", - "asian", + "DAO", + "Governance", + "asia", "Coordination", - "Political systems", - "Regenative Ethereum", - "Solarpunk" - ], - "keywords": [ - "asian", - "values" + "DAO", + "Governance" ], - "duration": 1568, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "rhDemdcnVVE", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731390600000, - "slot_end": 1731392400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg", - "resources_slides": null, "speakers": [ - "dev-lewis" - ] + "joseph-low", + "hazel-devjani", + "gen", + "yvonne", + "vivian-chen" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731475800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE" }, "vector": [ 0, @@ -618104,15 +618583,12 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -618647,10 +619123,14 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -618932,17 +619412,18 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -618961,7 +619442,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -619210,7 +619690,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -619221,7 +619700,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -619400,6 +619879,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -619407,11 +619887,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -619420,39 +619900,50 @@ }, { "session": { - "id": "remix-jazz-and-blues-jam", - "sourceId": "P8DPWB", - "title": "Remix Jazz and Blues Jam", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution", + "sourceId": "FKVE9X", + "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution", + "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "RPC", + "Execution" + ], + "tags": [ + "Scalability", + "EVM-equivalent", + "Tooling", + "execution", + "EVM-equivalent", + "Scalability", + "Tooling" + ], "language": "en", - "speakers": [], + "speakers": [ + "everton-fraga" + ], "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731398400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw" + "slot_start": 1731565200000, + "slot_end": 1731565800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -619994,6 +620485,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -620202,6 +620694,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -620320,6 +620813,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -620376,6 +620870,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -620502,6 +620997,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -620743,8 +621239,6 @@ 0, 0, 2, - 0, - 0, 2, 0, 0, @@ -620763,25 +621257,50 @@ }, { "session": { - "id": "remix-team-jazz-jam", - "sourceId": "DFPGS9", - "title": "Remix Team Jazz Jam", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies", + "sourceId": "JPHQYQ", + "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies", + "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Academic", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "tags": [ + "Coordination", + "Political systems", + "Solarpunk", + "Regenative Ethereum", + "value", + "asian", + "Coordination", + "Political systems", + "Regenative Ethereum", + "Solarpunk" + ], + "keywords": [ + "asian", + "values" + ], + "duration": 1568, "language": "en", - "speakers": [], + "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67", + "sources_youtubeId": "rhDemdcnVVE", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731564000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M" + "slot_start": 1731390600000, + "slot_end": 1731392400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg", + "resources_slides": null, + "speakers": [ + "dev-lewis" + ] }, "vector": [ 0, @@ -620790,12 +621309,7 @@ 0, 0, 0, - 0, - 0, - 0, - 6, - 0, - 0, + 6, 0, 0, 0, @@ -621341,6 +621855,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -621633,6 +622148,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -621651,6 +622167,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -621680,6 +622197,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -621898,6 +622416,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -621908,6 +622427,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -621979,6 +622499,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622088,8 +622609,6 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, @@ -622098,6 +622617,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622106,39 +622626,28 @@ }, { "session": { - "id": "resilience-to-global-catastrophes", - "sourceId": "PZFHQF", - "title": "Resilience to Global Catastrophes", - "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "remix-jazz-and-blues-jam", + "sourceId": "P8DPWB", + "title": "Remix Jazz and Blues Jam", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Resilience", - "global catastrophic risk" - ], - "tags": [ - "Climate", - "DAO", - "Effective Altruism" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "david-denkenberger", - "yesh" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731582600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U" + "slot_start": 1731391200000, + "slot_end": 1731398400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw" }, "vector": [ 0, - 6, 0, 0, 0, @@ -622147,6 +622656,12 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -622690,8 +623205,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -622976,7 +623489,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -623010,7 +623522,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -623065,7 +623576,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -623441,6 +623951,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -623459,39 +623970,32 @@ }, { "session": { - "id": "reth-10-how-did-we-get-here-and-what-is-next", - "sourceId": "UTDCDM", - "title": "Reth 1.0: How did we get here and what is next?", - "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "remix-team-jazz-jam", + "sourceId": "DFPGS9", + "title": "Remix Team Jazz Jam", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "rust" - ], - "tags": [ - "Core Protocol", - "Developer Infrastructure", - "Tooling", - "rust", - "Core Protocol", - "Developer Infrastructure", - "Tooling" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "georgios-konstantopoulos" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU" + "slot_start": 1731556800000, + "slot_end": 1731564000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -624047,7 +624551,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -624249,9 +624752,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -624284,7 +624785,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -624688,7 +625188,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -624792,9 +625291,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -624814,46 +625314,42 @@ }, { "session": { - "id": "rethinking-ethereums-account-model", - "sourceId": "GEEQXS", - "title": "Rethinking Ethereum’s account model", - "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.", - "track": "Core Protocol", + "id": "resilience-to-global-catastrophes", + "sourceId": "PZFHQF", + "title": "Resilience to Global Catastrophes", + "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Expert", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Account", - "Models" + "Resilience", + "global catastrophic risk" ], "tags": [ - "Core Protocol", - "Layer 1", - "Ethereum Roadmap", - "model", - "account", - "Core Protocol", - "Ethereum Roadmap", - "Layer 1" + "Climate", + "DAO", + "Effective Altruism" ], "language": "en", "speakers": [ - "will-villanueva" + "david-denkenberger", + "yesh" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731466500000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE" + "slot_start": 1731582000000, + "slot_end": 1731582600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U" }, "vector": [ 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -625402,10 +625898,12 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -625602,11 +626100,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -625689,6 +626185,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -625722,6 +626219,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -625776,6 +626274,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -625824,7 +626323,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -626046,8 +626544,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -626153,6 +626649,7 @@ 0, 0, 2, + 0, 2, 0, 0, @@ -626171,48 +626668,49 @@ }, { "session": { - "id": "rethinking-usability-in-a-world-of-data-ownership", - "sourceId": "RKNJED", - "title": "Rethinking usability in a world of data ownership", - "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.", - "track": "Usability", + "id": "reth-10-how-did-we-get-here-and-what-is-next", + "sourceId": "UTDCDM", + "title": "Reth 1.0: How did we get here and what is next?", + "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Beginner", - "audience": "", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "applications", - "social graphs", - "data ownership" + "rust" ], "tags": [ - "data", - "ownership", - "Best Practices", - "Design Thinking", - "MPC" + "Core Protocol", + "Developer Infrastructure", + "Tooling", + "rust", + "Core Protocol", + "Developer Infrastructure", + "Tooling" ], "language": "en", "speakers": [ - "rachel" + "georgios-konstantopoulos" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM" + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU" }, "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -626758,10 +627256,24 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -626947,6 +627459,15 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -627031,7 +627552,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -627086,7 +627606,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -627252,7 +627771,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -627380,6 +627898,26 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -627403,45 +627941,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, @@ -627503,6 +628002,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -627518,62 +628018,52 @@ 0, 0, 0, - 2, - 0, 0, 0 ] }, { "session": { - "id": "rethinking-user-risks-at-l2beat", - "sourceId": "8YKV8H", - "title": "Rethinking user risks at L2BEAT", - "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.", - "track": "Security", + "id": "rethinking-ethereums-account-model", + "sourceId": "GEEQXS", + "title": "Rethinking Ethereum’s account model", + "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.", + "track": "Core Protocol", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Layer 2s", - "Token bridging", - "Security", - "trusted", - "Layer 2s", - "Security", - "Token bridging" - ], "keywords": [ - "risk", - "trust" + "Account", + "Models" + ], + "tags": [ + "Core Protocol", + "Layer 1", + "Ethereum Roadmap", + "model", + "account", + "Core Protocol", + "Ethereum Roadmap", + "Layer 1" ], - "duration": 523, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "CM6e_wwieeo", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "will-villanueva" + ], "eventId": "devcon-7", - "slot_start": 1731406800000, - "slot_end": 1731407400000, + "slot_start": 1731465900000, + "slot_end": 1731466500000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw", - "resources_slides": null, - "speakers": [ - "piotr-szlachciak" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE" }, "vector": [ - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -628125,9 +628615,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -628307,7 +628797,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -628324,9 +628813,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -628373,7 +628864,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -628479,7 +628969,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -628503,6 +628992,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -628510,7 +629000,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -628768,6 +629257,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -628869,16 +629360,16 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -628891,39 +629382,39 @@ }, { "session": { - "id": "reverse-engineering-evm-bytecode-with-ghidra", - "sourceId": "GSJ8EC", - "title": "Reverse Engineering EVM Bytecode with Ghidra", - "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.", - "track": "Security", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "rethinking-usability-in-a-world-of-data-ownership", + "sourceId": "RKNJED", + "title": "Rethinking usability in a world of data ownership", + "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.", + "track": "Usability", + "type": "Talk", + "expertise": "Beginner", + "audience": "", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Security" + "applications", + "social graphs", + "data ownership" ], "tags": [ - "Security", - "Reversing", - "Reversing" + "data", + "ownership", + "Best Practices", + "Design Thinking", + "MPC" ], "language": "en", "speakers": [ - "yuejie", - "louis-tsai" + "rachel" ], "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731659400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0" + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM" }, "vector": [ - 6, - 0, - 0, 0, 0, 0, @@ -628932,6 +629423,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -629481,7 +629973,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -629659,7 +630150,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -629695,6 +630185,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -629752,6 +630243,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -629806,6 +630298,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -629972,6 +630465,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -630221,7 +630715,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -630237,39 +630730,57 @@ 0, 0, 0, + 2, + 0, 0, 0 ] }, { "session": { - "id": "review-is-dead-long-live-review", - "sourceId": "HZUMTT", - "title": "Review is dead; long live review", - "description": "Low-quality AI outputs are overwhelming our review systems (from code review to judicial review). As AI systems get more capable, this problem gets worse. Solving alignment lets you abdicate review, but brings political and ethical problems.\r\nThe alternative to alignment is scaling human review. Researchers are designing architectures to review general intelligence but I'll present tools and systems that can be built now to scale review of AI outputs in specific domains (e.g. software, molecules)", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "rethinking-user-risks-at-l2beat", + "sourceId": "8YKV8H", + "title": "Rethinking user risks at L2BEAT", + "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.", + "track": "Security", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, + "tags": [ + "Layer 2s", + "Token bridging", + "Security", + "trusted", + "Layer 2s", + "Security", + "Token bridging" + ], "keywords": [ - "AI", - "d/acc" + "risk", + "trust" ], - "tags": [], + "duration": 523, "language": "en", - "speakers": [ - "evan-miyazono" - ], + "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9", + "sources_youtubeId": "CM6e_wwieeo", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1mjmEh7Mp_muTaryIzLnVyKvNQ_TDozx2Ilmslu4ZO54" + "slot_start": 1731406800000, + "slot_end": 1731407400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw", + "resources_slides": null, + "speakers": [ + "piotr-szlachciak" + ] }, "vector": [ - 0, 6, 0, 0, @@ -630828,8 +631339,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -631011,6 +631520,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -631076,6 +631586,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631181,6 +631692,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631213,6 +631725,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -631552,84 +632080,65 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "revm-endgame", - "sourceId": "VEEYFZ", - "title": "Revm Endgame", - "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.", - "track": "Core Protocol", - "type": "Talk", + "id": "reverse-engineering-evm-bytecode-with-ghidra", + "sourceId": "GSJ8EC", + "title": "Reverse Engineering EVM Bytecode with Ghidra", + "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.", + "track": "Security", + "type": "Workshop", "expertise": "Intermediate", "audience": "Engineering", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "EVM" + "Security" ], "tags": [ - "Core Protocol", - "Architecture", - "Public good", - "execution", - "client", - "Architecture", - "Core Protocol", - "Public good" + "Security", + "Reversing", + "Reversing" ], "language": "en", "speakers": [ - "dragan-rakita" + "yuejie", + "louis-tsai" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs" + "slot_start": 1731654000000, + "slot_end": 1731659400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0" }, "vector": [ + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -632184,10 +632693,11 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -632363,6 +632873,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -632382,7 +632893,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -632425,7 +632935,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -632472,7 +632981,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -632558,7 +633066,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -632828,6 +633335,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -632947,38 +633457,32 @@ }, { "session": { - "id": "revolutionizing-liquidity-the-cow-amm-approach", - "sourceId": "8DCP9K", - "title": "Revolutionizing Liquidity: The CoW AMM Approach", - "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "review-is-dead-long-live-review", + "sourceId": "HZUMTT", + "title": "Review is dead; long live review", + "description": "Low-quality AI outputs are overwhelming our review systems (from code review to judicial review). As AI systems get more capable, this problem gets worse. Solving alignment lets you abdicate review, but brings political and ethical problems.\r\nThe alternative to alignment is scaling human review. Researchers are designing architectures to review general intelligence but I'll present tools and systems that can be built now to scale review of AI outputs in specific domains (e.g. software, molecules)", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "LVR" - ], - "tags": [ - "MEV", - "AMMs", - "lvr", - "AMMs", - "MEV" + "AI", + "d/acc" ], + "tags": [], "language": "en", "speakers": [ - "anna-george" + "evan-miyazono" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731565800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk" + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1mjmEh7Mp_muTaryIzLnVyKvNQ_TDozx2Ilmslu4ZO54" }, "vector": [ - 0, 0, 6, 0, @@ -633540,7 +634044,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -633718,7 +634221,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -633799,7 +634301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -634179,7 +634680,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -634278,7 +634778,10 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -634295,42 +634798,48 @@ 0, 0, 0, + 2, + 0, + 0, 0 ] }, { "session": { - "id": "rip-7755-empowering-cross-chain-interactions", - "sourceId": "787TJ7", - "title": "RIP-7755: Empowering Cross-Chain Interactions", - "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.", - "track": "Layer 2", - "type": "Workshop", + "id": "revm-endgame", + "sourceId": "VEEYFZ", + "title": "Revm Endgame", + "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Interop" + "EVM" ], "tags": [ - "Cross-L2", - "Rollups" + "Core Protocol", + "Architecture", + "Public good", + "execution", + "client", + "Architecture", + "Core Protocol", + "Public good" ], "language": "en", "speakers": [ - "jack-chuma" + "dragan-rakita" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731652200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc" + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs" }, "vector": [ - 0, - 0, - 0, 0, 0, 0, @@ -634892,6 +635401,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -635088,6 +635598,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -635108,7 +635620,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -635130,6 +635641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -635176,6 +635688,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -635263,10 +635776,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -635650,47 +636163,37 @@ }, { "session": { - "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks", - "sourceId": "ZFJXFP", - "title": "RLNv2: enhanced spam protection for all peer-to-peer networks", - "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.", - "track": "Cypherpunk & Privacy", - "type": "Workshop", + "id": "revolutionizing-liquidity-the-cow-amm-approach", + "sourceId": "8DCP9K", + "title": "Revolutionizing Liquidity: The CoW AMM Approach", + "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Anonymity", - "peer-to-peer networks" + "LVR" ], "tags": [ - "Privacy", - "Censorship Resistance", - "Decentralization", - "Zero-Knowledge", - "network", - "peer-to-peer", - "Censorship Resistance", - "Decentralization", - "Privacy", - "Zero-Knowledge" + "MEV", + "AMMs", + "lvr", + "AMMs", + "MEV" ], "language": "en", "speakers": [ - "franck-royer", - "alvaro" + "anna-george" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731488400000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ" + "slot_start": 1731564000000, + "slot_end": 1731565800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk" }, "vector": [ - 0, - 0, - 0, 0, 0, 6, @@ -635796,10 +636299,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -636253,14 +636752,12 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -636514,15 +637011,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -636543,17 +637031,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -636574,8 +637051,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -636890,8 +637365,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -636923,6 +637396,35 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -636988,7 +637490,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -636999,6 +637500,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -637010,44 +637517,32 @@ }, { "session": { - "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs", - "sourceId": "NHERZE", - "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs", - "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.", - "track": "Coordination", - "type": "Lightning Talk", + "id": "rip-7755-empowering-cross-chain-interactions", + "sourceId": "787TJ7", + "title": "RIP-7755: Empowering Cross-Chain Interactions", + "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.", + "track": "Layer 2", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Grants Program", - "Public Goods Funding" + "Interop" ], "tags": [ - "Coordination", - "DAO", - "Governance", - "Regenative Ethereum", - "Public good", - "funding", - "public", - "goods", - "Coordination", - "DAO", - "Governance", - "Public good", - "Regenative Ethereum" + "Cross-L2", + "Rollups" ], "language": "en", "speakers": [ - "shinya-mori" + "jack-chuma" ], "eventId": "devcon-7", - "slot_start": 1731640800000, - "slot_end": 1731641400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4" + "slot_start": 1731645000000, + "slot_end": 1731652200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc" }, "vector": [ 0, @@ -637057,11 +637552,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -637613,10 +638109,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -637830,6 +638326,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -637884,12 +638382,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -637897,7 +638393,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -637943,7 +638438,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -637992,6 +638486,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -638101,7 +638598,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -638173,7 +638669,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -638253,8 +638748,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -638350,10 +638843,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, + 0, 0, 2, 0, @@ -638367,51 +638862,56 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "robust-restaking-networks", - "sourceId": "MERZWK", - "title": "Robust Restaking Networks", - "description": "We study the risks of validator reuse across multiple services in a restaking protocol. We characterize the robust security of a restaking network as a function of the buffer between the costs and profits from attacks. We also provide local analogs of these guarantees that apply specifically for a target service or coalition of services. Our results suggest measures of robustness that could be exposed to the participants in a restaking protocol. Full paper: https://arxiv.org/abs/2407.21785", - "track": "Cryptoeconomics", - "type": "Lightning Talk", + "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks", + "sourceId": "ZFJXFP", + "title": "RLNv2: enhanced spam protection for all peer-to-peer networks", + "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.", + "track": "Cypherpunk & Privacy", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Risk", - "Measurement", - "and", - "Mitigation" + "Anonymity", + "peer-to-peer networks" ], "tags": [ - "Economics", - "Restaking" + "Privacy", + "Censorship Resistance", + "Decentralization", + "Zero-Knowledge", + "network", + "peer-to-peer", + "Censorship Resistance", + "Decentralization", + "Privacy", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "naveen-durvasula" + "franck-royer", + "alvaro" ], "eventId": "devcon-7", - "slot_start": 1731486000000, - "slot_end": 1731486600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19pt0uKTgDWFeqwxxWBjlyG912sJ3Ez2L29Niax82m9w" + "slot_start": 1731483000000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ" }, "vector": [ - 0, - 0, - 6, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -638514,6 +639014,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -639156,6 +639657,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -639176,8 +639678,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -639233,6 +639733,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -639246,6 +639747,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -639260,6 +639762,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -639290,6 +639793,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -639510,7 +640014,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -639606,6 +640109,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -639707,9 +640211,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -639725,35 +640229,44 @@ }, { "session": { - "id": "rohingya-decentralized-identity-and-community-building", - "sourceId": "G8W8MU", - "title": "Rohingya Decentralized Identity and Community Building", - "description": "The Rohingya Project is a transformative digital platform addressing the critical needs of the Rohingya community, focusing on empowerment and cultural preservation. Key services include R-ID, a decentralized identity verification system ensuring privacy and access to opportunities, and R-Academy, which offers courses on Rohingya culture and personal development. The Heritage Archive provides access to cultural resources, while the Community Exchange fosters collaboration & economic development.", - "track": "Real World Ethereum", + "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs", + "sourceId": "NHERZE", + "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs", + "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Rohingya", - "Decentralized Identity", - "inclusion" + "Grants Program", + "Public Goods Funding" ], "tags": [ - "Decentralization", - "Digital Sovereignty", - "Ethereum for Good" + "Coordination", + "DAO", + "Governance", + "Regenative Ethereum", + "Public good", + "funding", + "public", + "goods", + "Coordination", + "DAO", + "Governance", + "Public good", + "Regenative Ethereum" ], "language": "en", "speakers": [ - "muhammad-noor" + "shinya-mori" ], "eventId": "devcon-7", - "slot_start": 1731572400000, - "slot_end": 1731573000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1UYUaHo5Qavbvjs-V4IY1wgEZga3-zWvPCG7PXENX-k4" + "slot_start": 1731640800000, + "slot_end": 1731641400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4" }, "vector": [ 0, @@ -639762,14 +640275,12 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -640544,9 +641055,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -640601,25 +641109,6 @@ 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, @@ -640628,6 +641117,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -640673,6 +641163,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -640831,6 +641322,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -640901,6 +641393,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -640980,6 +641473,38 @@ 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, @@ -641041,30 +641566,15 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -641073,53 +641583,53 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "running-ethereum-node-in-africa", - "sourceId": "XT8ZWL", - "title": "Running Ethereum Node In Africa", - "description": "Running an Ethereum node in Africa presents both challenges and opportunities. It enables participation in the global blockchain ecosystem while contributing to network security and decentralization. Key points to highlight include overcoming infrastructure limitations, leveraging community support, the potential for economic empowerment through staking, and fostering local innovation and adoption. Emphasize the importance of education, collaboration, and strategic partnerships to", - "track": "Real World Ethereum", + "id": "robust-restaking-networks", + "sourceId": "MERZWK", + "title": "Robust Restaking Networks", + "description": "We study the risks of validator reuse across multiple services in a restaking protocol. We characterize the robust security of a restaking network as a function of the buffer between the costs and profits from attacks. We also provide local analogs of these guarantees that apply specifically for a target service or coalition of services. Our results suggest measures of robustness that could be exposed to the participants in a restaking protocol. Full paper: https://arxiv.org/abs/2407.21785", + "track": "Cryptoeconomics", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Stakers/Validators", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Geographical", - "Diversity" + "Risk", + "Measurement", + "and", + "Mitigation" ], "tags": [ - "Home staking", - "Distributed validator technology", - "Decentralization", - "diversity", - "geographical", - "Decentralization", - "Distributed validator technology", - "Home staking" + "Economics", + "Restaking" ], "language": "en", "speakers": [ - "david-uzochukwu" + "naveen-durvasula" ], "eventId": "devcon-7", - "slot_start": 1731575400000, - "slot_end": 1731576000000, + "slot_start": 1731486000000, + "slot_end": 1731486600000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1buMXIg1gOhRzKk22wUllHQbcl9xVPk1mQ7_JHDKF_oQ" + "resources_presentation": "https://docs.google.com/presentation/d/19pt0uKTgDWFeqwxxWBjlyG912sJ3Ez2L29Niax82m9w" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -641515,7 +642025,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -641681,6 +642190,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -641887,6 +642397,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -641937,7 +642448,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641953,7 +642463,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641981,7 +642490,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -642223,6 +642731,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -642318,8 +642831,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -642417,13 +642928,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -642435,57 +642946,44 @@ }, { "session": { - "id": "running-wargames-to-prepare-protocol-teams-for-incident-response", - "sourceId": "N3DBC3", - "title": "Running Wargames to Prepare Protocol Teams for Incident Response", - "description": "SEAL (Security Alliance) Wargames: cybersecurity exercises designed to enhance Web3 protocol resilience. We'll share experiences from running these with major Ethereum protocols, covering:\r\n-Exercise structure: OSINT, tabletops, and live simulations on forked networks\r\n-Scenario designs and common vulnerabilities\r\n-Infrastructure and open-source tooling\r\n-Key learnings and best practices\r\n-Scaling strategies and the importance of regular security drills in the evolving Web3 landscape", - "track": "Security", - "type": "Talk", + "id": "rohingya-decentralized-identity-and-community-building", + "sourceId": "G8W8MU", + "title": "Rohingya Decentralized Identity and Community Building", + "description": "The Rohingya Project is a transformative digital platform addressing the critical needs of the Rohingya community, focusing on empowerment and cultural preservation. Key services include R-ID, a decentralized identity verification system ensuring privacy and access to opportunities, and R-Academy, which offers courses on Rohingya culture and personal development. The Heritage Archive provides access to cultural resources, while the Community Exchange fosters collaboration & economic development.", + "track": "Real World Ethereum", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Coordination", - "Security", - "incident", - "response", - "Coordination", - "Security" - ], "keywords": [ - "Incident", - "Response" + "Rohingya", + "Decentralized Identity", + "inclusion" + ], + "tags": [ + "Decentralization", + "Digital Sovereignty", + "Ethereum for Good" ], - "duration": 1350, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "9UBmda-mqGs", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732febd80d989c5b7b49fc9.vtt", - "transcript_text": " And I also lead the War Games initiative for the Security Alliance. I'll give a brief introduction to just what the Security Alliance is and what the various initiatives are, because I think it's actually pretty relevant also after the first talk about ENS and data sharing. And so the top initiative here is actually called the SEAL-ISAC, which is not me, I'm SEAL-ISAC. This is the Information Security something something, which basically this is like a shared database between many different companies where they can share data on like DPRK threat actors or phishing data or bad domains. There's SEAL War Games, which is the initiative that I lead, where we prepare protocol teams for incident response through both tabletop simulations and then live simulations on forked environments. SEAL also operates SEAL 911, the emergency hotline, if your protocol is under attack or if you have discovered a vulnerability in a protocol and need to get in touch with a security expert as fast as possible. The Safe Harbor Agreement, which is legal protection if you're a white hat hacker and you're acting benevolently in an urgent situation to rescue funds from a protocol. Think Nomad Bridge hack a few years ago if you were trying to save money, but maybe you were worried because you thought that you'd be sued for hacking during because it'd be impossible to distinguish. The White Hat Safe Harbor Agreement exists to protect white hat hackers in those situations and a legal defense fund in case they sue you anyway. So today what we'll talk about primarily is war games. So what are these war games and why do we do them? I'll have some links to resources on how you can work with us. There's a lot of open source toolkits and we also run these as like a public good throughout the space. We'll be talking through some best practices that I've learned from working with some of the major protocols in the ecosystem and then just briefly show you what this new toolkit is that we released so you can run these yourself if you would like. So what are wargames? These are cybersecurity exercises for Web3. I've heard traditional cybersecurity folks call these something like a purple team exercise, where we're not exactly red team, blue team, but we're basically just trying to stress test these teams and understand how they behave under pressure. And so we want to help teams practice for these high-pressure situations before they actually happen. We want to be able to test both the technical side of their team and their social resilience. And we're not just trying to help cause them to panic, but we want them to practice emergency response. A lot of the reason why we started doing this was a few years ago. So the security lines was started by Sam Sun, and he was pulled into so many war rooms where it seemed like, I guess, from what I've heard, teams just completely melting down and not really being exactly prepared for what would happen. So what could we actually do to help put them in that situation before that inevitably happens? So war games take place through three phases. I do a lot of intelligence gathering, which really just means reading every document that the protocol's ever published, understand their contracts, understand how it works. We do a tabletop exercise where we talk through various scenarios with them and understand how they would have detected them, what they would do, who's in charge, and how would they have fixed something. And then what I think is the most fun is we do a live simulation. So we set up a forked environment, we run all of their contracts, we write all of their UIs, we run all of their monitoring, and then they actually have to coordinate in real time to defend and respond as if it was a real incident. And we tend to find a lot of things that they can improve through that process, and it also just helps the team build trust in each other so that they know when an incident goes down for real, I can trust my team to be there. So a big reason why we do this is because more and more hacks are due to operational failures, not smart contract bugs. That's a really, I think, good sign that we're making fewer and fewer dumb mistakes on the smart contract side. However, as all of the stuff that we're building is becoming such a critical component of global financial infrastructure, the stakes are higher to actually operationally be strong as well. And so whether that's things like supply chain attacks or social engineering, it's much harder now than just not including dumb bugs in your smart contracts. So these are cross-functional exercises. We're not just working with the development team. They're of course a core part of it, but we're also tending to work with their auditors if they're a big protocol that has a guardian multi-sig that's in charge of pausing the protocol in case of emergency. We of course work with them. Communications team is actually essential so that we know what would they be communicating out to the public and when during an incident and legal so that they can say, okay, if we were to take this action perhaps to protect the users of our protocol, can we do that? Should we do that? And what should we be saying? The conversations between communications, legal, and devs should really be things that are figured out in advance so that during the incident,'re not thinking like do we tweet out that we're under attack right now or do we say something cryptic or what do we say like these are things that you can just have in a playbook so that you don't have to think about it in the moment. We've worked with a number of products of protocols so far but the purpose of this slide is also just to show you like why teams are working with us, it's because teams are growing. These are global teams, and it's really hard to prepare for this type of thing. There's many ways to engage with us. If you're a protocol that wants to work with a security alliance and have a drill performed with you, there's a form on the website, and there's also open source resources for you to be able to run these yourself. So this is a quote that I had a really hard time attributing. The internet said it was either like a Greek poet or the Navy Seals, but I think that it really like stands to to show like why we do this and it's that under pressure we don't rise to the occasion, we sink to our level of training. Yeah I think that that speaks to why we do this. So each one of these builds is quite different. A lot of protocols have various sorts of custom infrastructure and monitoring. So every time we do this, we end up having to build a lot of things. And we've tried to combine all of those tools and things that we've learned on how to run these simulations into this drill template that you can see here. It's on the Security Alliance GitHub repository. But what are the things that we do to make the environment feel realistic? So we of course have to run a network fork. We're usually either doing that with Anvil or with Tenderly. We have to run a block explorer, so we're either running Block Scout or using a virtual test net. We're running monitoring, so it's essential to mirror the same monitoring that you would have on main net.", - "eventId": "devcon-7", - "slot_start": 1731390600000, - "slot_end": 1731392400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE", - "resources_slides": null, "speakers": [ - "isaac-patka", - "kelsie-nabben" - ] + "muhammad-noor" + ], + "eventId": "devcon-7", + "slot_start": 1731572400000, + "slot_end": 1731573000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1UYUaHo5Qavbvjs-V4IY1wgEZga3-zWvPCG7PXENX-k4" }, "vector": [ - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -643048,7 +643546,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -643216,7 +643713,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -643270,6 +643766,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -643320,6 +643818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -643343,6 +643842,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -643371,7 +643874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -643685,8 +644187,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -643786,8 +644286,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -643800,32 +644300,39 @@ }, { "session": { - "id": "samba-a-besu-portal-client", - "sourceId": "FTC8PQ", - "title": "Samba, a Besu Portal Client", - "description": "A presentation about my experience participating in the EPF. Talking primarily about the project I worked on for the cohort and various obstacles that I faced along the way. I additionally aim to go into detail about where I see Samba going in the future and my role in that development.", - "track": "[CLS] EPF Day", + "id": "running-ethereum-node-in-africa", + "sourceId": "XT8ZWL", + "title": "Running Ethereum Node In Africa", + "description": "Running an Ethereum node in Africa presents both challenges and opportunities. It enables participation in the global blockchain ecosystem while contributing to network security and decentralization. Key points to highlight include overcoming infrastructure limitations, leveraging community support, the potential for economic empowerment through staking, and fostering local innovation and adoption. Emphasize the importance of education, collaboration, and strategic partnerships to", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "EPF" + "Geographical", + "Diversity" ], "tags": [ - "Portal", - "network" + "Home staking", + "Distributed validator technology", + "Decentralization", + "diversity", + "geographical", + "Decentralization", + "Distributed validator technology", + "Home staking" ], "language": "en", "speakers": [ - "derek-sorken" + "david-uzochukwu" ], "eventId": "devcon-7", - "slot_start": 1731471300000, - "slot_end": 1731472200000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1V8MPOsuS_Y8NmrHqykkqj248dMqY5xfRkNholeY8m_Q" + "slot_start": 1731575400000, + "slot_end": 1731576000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1buMXIg1gOhRzKk22wUllHQbcl9xVPk1mQ7_JHDKF_oQ" }, "vector": [ 0, @@ -643834,6 +644341,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -643843,7 +644351,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -644230,6 +644737,21 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -644399,7 +644921,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -644639,6 +645160,35 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -644991,6 +645541,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -645037,51 +645590,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, @@ -645134,11 +645642,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -645150,48 +645658,55 @@ }, { "session": { - "id": "satellite-based-cryptographic-layer-extra-terrestial-extension-to-ethereum", - "sourceId": "SZBQLK", - "title": "Satellite based Cryptographic Layer - Extra-terrestial Extension to Ethereum", - "description": "Using nano-satellites with edge compute units we will show how we intend to build an orbital compute layer with unique properties. We will propose a novel cryptographic applications layer built with vision to space explorations.\r\n\r\nTypically public blockchains enable cryptographic primitives for the digital commons on earth, we will share novel implementation of cryptographic applications that will extend the digital commons into Low Earth Orbit (LEO) and import cryptographic resources from LEO.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", + "id": "running-wargames-to-prepare-protocol-teams-for-incident-response", + "sourceId": "N3DBC3", + "title": "Running Wargames to Prepare Protocol Teams for Incident Response", + "description": "SEAL (Security Alliance) Wargames: cybersecurity exercises designed to enhance Web3 protocol resilience. We'll share experiences from running these with major Ethereum protocols, covering:\r\n-Exercise structure: OSINT, tabletops, and live simulations on forked networks\r\n-Scenario designs and common vulnerabilities\r\n-Infrastructure and open-source tooling\r\n-Key learnings and best practices\r\n-Scaling strategies and the importance of regular security drills in the evolving Web3 landscape", + "track": "Security", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "space", - "frontier" - ], "tags": [ - "Network State", - "Use cases of cryptography", - "DePIN", - "space", - "frontier", - "DePIN", - "Network State", - "Use cases of cryptography" + "Coordination", + "Security", + "incident", + "response", + "Coordination", + "Security" ], - "language": "en", - "speakers": [ - "daniel-bar", - "matej-yangwao" + "keywords": [ + "Incident", + "Response" ], + "duration": 1350, + "language": "en", + "sources_swarmHash": "702aabf1c42143159cad1c657c1247f880937f9ed6f493fa9a9bdf4323e70723", + "sources_youtubeId": "9UBmda-mqGs", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732febd80d989c5b7b49fc9.vtt", + "transcript_text": " And I also lead the War Games initiative for the Security Alliance. I'll give a brief introduction to just what the Security Alliance is and what the various initiatives are, because I think it's actually pretty relevant also after the first talk about ENS and data sharing. And so the top initiative here is actually called the SEAL-ISAC, which is not me, I'm SEAL-ISAC. This is the Information Security something something, which basically this is like a shared database between many different companies where they can share data on like DPRK threat actors or phishing data or bad domains. There's SEAL War Games, which is the initiative that I lead, where we prepare protocol teams for incident response through both tabletop simulations and then live simulations on forked environments. SEAL also operates SEAL 911, the emergency hotline, if your protocol is under attack or if you have discovered a vulnerability in a protocol and need to get in touch with a security expert as fast as possible. The Safe Harbor Agreement, which is legal protection if you're a white hat hacker and you're acting benevolently in an urgent situation to rescue funds from a protocol. Think Nomad Bridge hack a few years ago if you were trying to save money, but maybe you were worried because you thought that you'd be sued for hacking during because it'd be impossible to distinguish. The White Hat Safe Harbor Agreement exists to protect white hat hackers in those situations and a legal defense fund in case they sue you anyway. So today what we'll talk about primarily is war games. So what are these war games and why do we do them? I'll have some links to resources on how you can work with us. There's a lot of open source toolkits and we also run these as like a public good throughout the space. We'll be talking through some best practices that I've learned from working with some of the major protocols in the ecosystem and then just briefly show you what this new toolkit is that we released so you can run these yourself if you would like. So what are wargames? These are cybersecurity exercises for Web3. I've heard traditional cybersecurity folks call these something like a purple team exercise, where we're not exactly red team, blue team, but we're basically just trying to stress test these teams and understand how they behave under pressure. And so we want to help teams practice for these high-pressure situations before they actually happen. We want to be able to test both the technical side of their team and their social resilience. And we're not just trying to help cause them to panic, but we want them to practice emergency response. A lot of the reason why we started doing this was a few years ago. So the security lines was started by Sam Sun, and he was pulled into so many war rooms where it seemed like, I guess, from what I've heard, teams just completely melting down and not really being exactly prepared for what would happen. So what could we actually do to help put them in that situation before that inevitably happens? So war games take place through three phases. I do a lot of intelligence gathering, which really just means reading every document that the protocol's ever published, understand their contracts, understand how it works. We do a tabletop exercise where we talk through various scenarios with them and understand how they would have detected them, what they would do, who's in charge, and how would they have fixed something. And then what I think is the most fun is we do a live simulation. So we set up a forked environment, we run all of their contracts, we write all of their UIs, we run all of their monitoring, and then they actually have to coordinate in real time to defend and respond as if it was a real incident. And we tend to find a lot of things that they can improve through that process, and it also just helps the team build trust in each other so that they know when an incident goes down for real, I can trust my team to be there. So a big reason why we do this is because more and more hacks are due to operational failures, not smart contract bugs. That's a really, I think, good sign that we're making fewer and fewer dumb mistakes on the smart contract side. However, as all of the stuff that we're building is becoming such a critical component of global financial infrastructure, the stakes are higher to actually operationally be strong as well. And so whether that's things like supply chain attacks or social engineering, it's much harder now than just not including dumb bugs in your smart contracts. So these are cross-functional exercises. We're not just working with the development team. They're of course a core part of it, but we're also tending to work with their auditors if they're a big protocol that has a guardian multi-sig that's in charge of pausing the protocol in case of emergency. We of course work with them. Communications team is actually essential so that we know what would they be communicating out to the public and when during an incident and legal so that they can say, okay, if we were to take this action perhaps to protect the users of our protocol, can we do that? Should we do that? And what should we be saying? The conversations between communications, legal, and devs should really be things that are figured out in advance so that during the incident,'re not thinking like do we tweet out that we're under attack right now or do we say something cryptic or what do we say like these are things that you can just have in a playbook so that you don't have to think about it in the moment. We've worked with a number of products of protocols so far but the purpose of this slide is also just to show you like why teams are working with us, it's because teams are growing. These are global teams, and it's really hard to prepare for this type of thing. There's many ways to engage with us. If you're a protocol that wants to work with a security alliance and have a drill performed with you, there's a form on the website, and there's also open source resources for you to be able to run these yourself. So this is a quote that I had a really hard time attributing. The internet said it was either like a Greek poet or the Navy Seals, but I think that it really like stands to to show like why we do this and it's that under pressure we don't rise to the occasion, we sink to our level of training. Yeah I think that that speaks to why we do this. So each one of these builds is quite different. A lot of protocols have various sorts of custom infrastructure and monitoring. So every time we do this, we end up having to build a lot of things. And we've tried to combine all of those tools and things that we've learned on how to run these simulations into this drill template that you can see here. It's on the Security Alliance GitHub repository. But what are the things that we do to make the environment feel realistic? So we of course have to run a network fork. We're usually either doing that with Anvil or with Tenderly. We have to run a block explorer, so we're either running Block Scout or using a virtual test net. We're running monitoring, so it's essential to mirror the same monitoring that you would have on main net.", "eventId": "devcon-7", - "slot_start": 1731648000000, - "slot_end": 1731648600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Net_UwG69ncJlQvHg5qG_nefAW16HDrDDKf-9OaDpsw" + "slot_start": 1731390600000, + "slot_end": 1731392400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE", + "resources_slides": null, + "speakers": [ + "isaac-patka", + "kelsie-nabben" + ] }, "vector": [ + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -645755,11 +646270,11 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -645925,6 +646440,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -645946,13 +646462,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -645971,7 +646485,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -646057,7 +646570,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -646083,6 +646595,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -646397,6 +646910,9 @@ 0, 0, 2, + 2, + 0, + 0, 0, 0, 0, @@ -646491,10 +647007,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -646508,43 +647024,37 @@ }, { "session": { - "id": "scalable-and-sovereign-evm-data-modern-data-engineering-best-practices", - "sourceId": "KEEUYL", - "title": "Scalable and sovereign EVM data: modern data engineering best practices", - "description": "Collecting and analyzing large historical EVM datasets can pose a significant challenge. This has led many teams and individuals to outsource their data infrastructure to commercial 3rd-party platforms. However, over the past year a new style of data workflow has emerged, using entirely open source software and local-first processing. This new ecosystem of tools allow anyone to cheaply, easily, and robustly collect and analyze any EVM dataset from the comfort of their own laptop.", - "track": "Developer Experience", - "type": "Talk", + "id": "samba-a-besu-portal-client", + "sourceId": "FTC8PQ", + "title": "Samba, a Besu Portal Client", + "description": "A presentation about my experience participating in the EPF. Talking primarily about the project I worked on for the cohort and various obstacles that I faced along the way. I additionally aim to go into detail about where I see Samba going in the future and my role in that development.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Data Engineering", - "Data Science", - "Data Analysis" + "EPF" ], "tags": [ - "Developer Infrastructure", - "data", - "analysis", - "Developer", - "Infrastructure" + "Portal", + "network" ], "language": "en", "speakers": [ - "storm-slivkoff" + "derek-sorken" ], "eventId": "devcon-7", - "slot_start": 1731573000000, - "slot_end": 1731574800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1ArYtVYufUwHpFKb-cm8W6DCWGSPca78nUlpjKQDTmiY" + "slot_start": 1731471300000, + "slot_end": 1731472200000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1V8MPOsuS_Y8NmrHqykkqj248dMqY5xfRkNholeY8m_Q" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -646557,6 +647067,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -646938,7 +647450,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -647112,6 +647623,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -647283,7 +647795,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -647333,7 +647844,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -647369,6 +647879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -647589,7 +648100,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -647753,7 +648263,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -647841,7 +648350,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -647851,6 +648359,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -647863,34 +648375,40 @@ }, { "session": { - "id": "scalable-multi-party-fhe-with-phantom-zone", - "sourceId": "SLJ9QS", - "title": "Scalable multi-party FHE with Phantom-zone", - "description": "The talk introduces \"phantom-zone\", a framework to write scalable consumer facing MPC apps using multi-party FHE. Starting with what's multi-party FHE, talk gives a demo of non-trivial MPC app. Followed by introduction to programming model of MPC apps using multi-party FHE inside phantom-zone. Then the talk dives deep into primitives to realise multi-party FHE and ends with advanced FHE gadgets that further enhance multi-party FHE.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "id": "satellite-based-cryptographic-layer-extra-terrestial-extension-to-ethereum", + "sourceId": "SZBQLK", + "title": "Satellite based Cryptographic Layer - Extra-terrestial Extension to Ethereum", + "description": "Using nano-satellites with edge compute units we will show how we intend to build an orbital compute layer with unique properties. We will propose a novel cryptographic applications layer built with vision to space explorations.\r\n\r\nTypically public blockchains enable cryptographic primitives for the digital commons on earth, we will share novel implementation of cryptographic applications that will extend the digital commons into Low Earth Orbit (LEO) and import cryptographic resources from LEO.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "FHE", - "MP-FHE" + "space", + "frontier" ], "tags": [ - "MPC", - "mp-fhe", - "MPC" + "Network State", + "Use cases of cryptography", + "DePIN", + "space", + "frontier", + "DePIN", + "Network State", + "Use cases of cryptography" ], "language": "en", "speakers": [ - "janmajaya-mall" + "daniel-bar", + "matej-yangwao" ], "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731569400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1V86Kc6aOcbAUsOm8NBUDaQ00YrCn0XJN5ce8Lyt73WU" + "slot_start": 1731648000000, + "slot_end": 1731648600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Net_UwG69ncJlQvHg5qG_nefAW16HDrDDKf-9OaDpsw" }, "vector": [ 0, @@ -647898,12 +648416,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -648313,7 +648831,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -648466,6 +648983,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -648653,11 +649172,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -648676,6 +649197,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -648720,7 +649242,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -648762,6 +649283,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -649085,6 +649622,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -649106,39 +649659,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, @@ -649192,10 +649712,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 2, 0, @@ -649209,53 +649729,52 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "scaling-autonomous-worlds-building-the-foundations-and-sewers-for-millions-of-inhabitants", - "sourceId": "QPAXL7", - "title": "Scaling autonomous worlds - building the foundations… and sewers for millions of inhabitants", - "description": "One tends to think of Ethereum scaling in financial terms—how many transactions per second? What’s the TVL? How much liquidity?\r\n\r\nBut in a possible future where Ethereum applications extend beyond finance, into areas like autonomous worlds, games, and social, what does scaling look like and what challenges await?\r\n\r\nJoin us as we explore challenges, solutions, and open questions in this space—how do we bring latency down despite seconds-long block time? Could we shard an app across multiple chains?", - "track": "Layer 2", + "id": "scalable-and-sovereign-evm-data-modern-data-engineering-best-practices", + "sourceId": "KEEUYL", + "title": "Scalable and sovereign EVM data: modern data engineering best practices", + "description": "Collecting and analyzing large historical EVM datasets can pose a significant challenge. This has led many teams and individuals to outsource their data infrastructure to commercial 3rd-party platforms. However, over the past year a new style of data workflow has emerged, using entirely open source software and local-first processing. This new ecosystem of tools allow anyone to cheaply, easily, and robustly collect and analyze any EVM dataset from the comfort of their own laptop.", + "track": "Developer Experience", "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Cross-chain" + "Data Engineering", + "Data Science", + "Data Analysis" ], "tags": [ - "Layer 2s", - "Cross-L2", - "Autonomous World", - "cross-chain", - "Autonomous World", - "Cross-L2", - "Layer 2s" + "Developer Infrastructure", + "data", + "analysis", + "Developer", + "Infrastructure" ], "language": "en", "speakers": [ - "tdot" + "storm-slivkoff" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/11DTfplHre4QguicqcET5ubMdfycNHdyjo8Imn5A0lWc" + "slot_start": 1731573000000, + "slot_end": 1731574800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1ArYtVYufUwHpFKb-cm8W6DCWGSPca78nUlpjKQDTmiY" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -649645,6 +650164,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -649822,7 +650342,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -649991,6 +650510,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -650040,6 +650560,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -650052,7 +650573,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -650096,7 +650616,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -650186,7 +650705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -650299,6 +650817,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -650460,9 +650979,10 @@ 0, 0, 0, + 2, + 2, 0, 0, - 2, 0, 0, 0, @@ -650570,29 +651090,36 @@ }, { "session": { - "id": "scaling-clean-air-now-and-the-future", - "sourceId": "RKA9MF", - "title": "Scaling Clean Air: Now and the Future", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", + "id": "scalable-multi-party-fhe-with-phantom-zone", + "sourceId": "SLJ9QS", + "title": "Scalable multi-party FHE with Phantom-zone", + "description": "The talk introduces \"phantom-zone\", a framework to write scalable consumer facing MPC apps using multi-party FHE. Starting with what's multi-party FHE, talk gives a demo of non-trivial MPC app. Followed by introduction to programming model of MPC apps using multi-party FHE inside phantom-zone. Then the talk dives deep into primitives to realise multi-party FHE and ends with advanced FHE gadgets that further enhance multi-party FHE.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "FHE", + "MP-FHE" + ], + "tags": [ + "MPC", + "mp-fhe", + "MPC" + ], "language": "en", - "speakers": [], + "speakers": [ + "janmajaya-mall" + ], "eventId": "devcon-7", - "slot_start": 1731570300000, - "slot_end": 1731571200000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1ZJZJ_2zvDgnrKFG8JEZo8VMp_Z1mb0btmMRtR2j0Vv0" + "slot_start": 1731567600000, + "slot_end": 1731569400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1V86Kc6aOcbAUsOm8NBUDaQ00YrCn0XJN5ce8Lyt73WU" }, "vector": [ - 0, - 6, 0, 0, 0, @@ -650603,6 +651130,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -651012,6 +651540,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -651419,6 +651948,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -651804,6 +652334,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -651894,7 +652425,6 @@ 0, 2, 0, - 0, 2, 0, 0, @@ -651913,60 +652443,47 @@ }, { "session": { - "id": "scaling-community-lessons-from-building-base", - "sourceId": "P73W8S", - "title": "Scaling Community: Lessons from Building Base", - "description": "Drawing from experiences as a Base core contributor and Base community lead, this talk is about building scalable Ethereum communities. Learn strategies for engagement, growth, best practices, and key insights.", - "track": "Developer Experience", - "type": "Lightning Talk", + "id": "scaling-autonomous-worlds-building-the-foundations-and-sewers-for-millions-of-inhabitants", + "sourceId": "QPAXL7", + "title": "Scaling autonomous worlds - building the foundations… and sewers for millions of inhabitants", + "description": "One tends to think of Ethereum scaling in financial terms—how many transactions per second? What’s the TVL? How much liquidity?\r\n\r\nBut in a possible future where Ethereum applications extend beyond finance, into areas like autonomous worlds, games, and social, what does scaling look like and what challenges await?\r\n\r\nJoin us as we explore challenges, solutions, and open questions in this space—how do we bring latency down despite seconds-long block time? Could we shard an app across multiple chains?", + "track": "Layer 2", + "type": "Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, + "keywords": [ + "Cross-chain" + ], "tags": [ - "Security", - "community", - "Layer 1", "Layer 2s", - "Values" - ], - "keywords": [ - "Community", - "Discord", - "Farcaster", - "Building Community", - "Community Management", - "Community Security" + "Cross-L2", + "Autonomous World", + "cross-chain", + "Autonomous World", + "Cross-L2", + "Layer 2s" ], - "duration": 574, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "7T9YaSIAk2s", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331c173a168eb535311ae1.vtt", - "transcript_text": " Tanya Cushman Reviewer Reviewer Hey everybody. Can everybody hear me okay? Pretty good? Alright. Thank you so much for coming here and being here today. So, hello friends. My name is Will Binz. I also go by W Binns. They're smashing my name together. I lead communities at Base. I'm also a full stack developer at Base. We're one and a half year old, layer two on top of Ethereum. Our objective is to build a global open economy that spreads equality, opportunity, and freedom around the world. We just processed our one billionth transaction this past week. It's still day one. And across Discord, Farcaster, GitHub, and X. There's millions of people that are part of our communities. I said hello friends, but we don't know each other. We're different genders, different skin colors. We come from different countries. There's all kinds of things that make us different here, that fracture us, that drive us apart, that lead to a lot of the conflict that we see in this world right now. But we're here. We're here together. All of us here left something behind that really wasn't working so well in some way. To look towards something better for us, for our friends, for our families, for our loved ones. And that, I think, is something that all of us can build a friendship on. And I think that's, in the context of this lightning talk, high level, our future is the most important part, focusing on that in building a scalable community. An open economy that anybody can be part of. Being able to work from wherever you want. Being able to live where you want, equality, all those things I talked about, all those things that make us different, all those things that don't matter, transparency, verifiability on chain, not having to take each other's word for things, freedom, and hopefully, in what we see these days in the future, more peace in the world. But how do we do that? We have to make space for everyone. Builders, creators, lurkers, people that are just curious, speculators, gamers, even scammers and spammers. There should be direct paths for all of these people. And in order to do that, we have to create opportunities for everyone. I just said scammers and spammers. And I think one of the most important parts of creating opportunity for scammers and spammers is being empathetic. There's people that are born just by the lottery of life in some part of the world where they can't even leave their town. They wish that they could get on a plane to come somewhere like this, to sit next to us today, but they can't do that. The opportunities in front of them led them to that path. It's up to us as community builders to build something better, to help people discover new apps, new opportunities, new jobs, learn, educate them. For some people, it's just to make friends, new friends, in a real world where they don't have any. And in all that, all of us, a better life. In order to do that, we have to focus on the fact that these problems in the world, these problems that we have with each other, across this EVM even, these things that make us different, these sub-communities that split us apart, that we see disagreements in, those problems are what unite us. They're not what should drive us apart. This EVM, Ethereum, is what connects us together. And so you as builders, building community, people, building apps across the EVM, across on-chain, an app is just something people download, but a community is something that you come back for. So what do we do? We have to realize and admit our mistakes when we have them. We have to realize we're not kings and queens. We're not royalty. Being in this space is a gift from the universe. But it's also a challenge. What am I? What are we? What are you going to do with this gift to be here today? To be able to fly here to Thailand. To be part of this community when others can't leave their own. To build something better. And there's a quote that's often cliche, but it's so true. Alone, we go fast, but together, we can go far. And so in that vein, I set up just a Telegram group. So anybody here, there's no difference in networks. We're all part of this Ethereum community. If you'd like to be part of this telegram, I'm an open book. People in our base community are open books. We're trying to build a better world together. Let's share our knowledge. Let's build a brain test. People watching this recording later, come to this group. Let's work together. Let's go through the things that we can't talk about in a lightning talk. How do we build safe, secure communities? How do we scale communities? How do we make sure that everybody has their space? So thank you all for sharing your time to be here today. Thank you so much, Will. Thank so much Will. Any questions? Please raise your hand I will throw this cube to you. Oh there's one there? Please help me. It's not a question, but a word of gratitude. Thank you for your talk. Thank you for your time. We highly need this kind of speech in the space like that. I just went out from a very different conversation. Respect. Thank you. Yeah. Thank you. Thank you. I see another question over there. Hi, Will. I saw you in person. How do you see communities like base Latin, base India, base Africa impact those communities? I think that thinking about like how all communities start, they start small. And in time, they grow. Some succeed, some fail, but if we think of things like on a cellular level, how human life imitates itself in the form of how we build communities, the ones that continue to get bigger and bigger and bigger, they divide and become their own communities. Taking Costa Rica as an example here, there's many builders in Costa Rica as an example here. There's many builders in Costa Rica, but in that, there's also many people with differences. There's people that want to build on chain, that just want to play games, they just want to trade, they just want to work on infra. And a lot of those people, they don't want to have anything to do with each other. That doesn't mean they don't like each other, they're just not interested. So for us as community builders, it's important that within the first 10, 15 seconds when they come into our community, we're helping them get to the right place. And so in the context of this question for based LATAM, which we're referring to here, which is based communities in Latin America, it's continuing to build more and more smaller and smaller and smaller communities until eventually we reach the grassroots. So that's my answer to the question.", - "eventId": "devcon-7", - "slot_start": 1731401400000, - "slot_end": 1731402000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Z6KNA8npIjlvXcTWwPrFhWHFQ9A2gd2wkiaNRb-bwuQ", - "resources_slides": null, "speakers": [ - "wbnns" - ] + "tdot" + ], + "eventId": "devcon-7", + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/11DTfplHre4QguicqcET5ubMdfycNHdyjo8Imn5A0lWc" }, "vector": [ 0, 0, 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -652696,7 +653213,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -652711,7 +653227,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -652762,11 +653277,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -652872,7 +653389,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -652901,6 +653417,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -653173,6 +653691,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -653262,12 +653781,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -653280,48 +653799,41 @@ }, { "session": { - "id": "scaling-crypto-theres-an-app-for-that-onboarding-millions-in-africa-with-minipay", - "sourceId": "EXCPST", - "title": "Scaling Crypto? There's an App for That. Onboarding Millions in Africa with MiniPay", - "description": "Post-EthCC, everyone’s talking about the industry’s influx of infra & lack of consumer apps. These conversations overlook the strides made in Africa with MiniPay, a self-custodial stablecoin wallet with 3M+ activated accounts since launching less than a year ago. In this panel, Rene, Yoseph & co-panelists will discuss building, scaling, & updating a truly user-friendly crypto wallet, introducing net new users to Web3 and dApps, & the power of ERC-20 stablecoins for payments in emerging markets.", - "track": "Real World Ethereum", + "id": "scaling-clean-air-now-and-the-future", + "sourceId": "RKA9MF", + "title": "Scaling Clean Air: Now and the Future", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "payment", - "p2p finance", - "mobile" - ], - "tags": [ - "Protocol Design", - "Scalability", - "UI/UX", - "Mobile", - "Protocol Design", - "Scalability", - "UI/UX" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "rene-reinsberg" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731575400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1lk319WDhop2qBsR_BdMLAl1tdzOwri17ao4IPguI7Ac" + "slot_start": 1731570300000, + "slot_end": 1731571200000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1ZJZJ_2zvDgnrKFG8JEZo8VMp_Z1mb0btmMRtR2j0Vv0" }, "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -653891,7 +654403,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -654076,7 +654587,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -654099,7 +654609,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -654112,7 +654621,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -654193,7 +654701,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -654615,6 +655122,7 @@ 0, 0, 0, + 2, 0, 0, 2, @@ -654623,8 +655131,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -654637,49 +655143,54 @@ }, { "session": { - "id": "scaling-ethereum-with-das-an-iterative-approach", - "sourceId": "JFWPRG", - "title": "Scaling Ethereum with DAS: an iterative approach", - "description": "In this time between the launch of 4844 and the possible launch of a first version of PeerDAS, we explore and explain the iterative approach that has been employed in the rollout of blobs and DAS to Ethereum, and discuss the past and future steps.", - "track": "Core Protocol", - "type": "Talk", + "id": "scaling-community-lessons-from-building-base", + "sourceId": "P73W8S", + "title": "Scaling Community: Lessons from Building Base", + "description": "Drawing from experiences as a Base core contributor and Base community lead, this talk is about building scalable Ethereum communities. Learn strategies for engagement, growth, best practices, and key insights.", + "track": "Developer Experience", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Community", "featured": false, "doNotRecord": false, "tags": [ - "Blobspace", - "Data Availability", - "Ethereum Roadmap", - "Scalability" + "Security", + "community", + "Layer 1", + "Layer 2s", + "Values" ], "keywords": [ - "PeerDAS" + "Community", + "Discord", + "Farcaster", + "Building Community", + "Community Management", + "Community Security" ], - "duration": 1522, + "duration": 574, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "toR2UKzE_zA", + "sources_swarmHash": "4e8c46194a8800b5909aeb01cc6c0324728e82519f7c0ad031cb1149411d564e", + "sources_youtubeId": "7T9YaSIAk2s", "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/67331c173a168eb535311ae1.vtt", + "transcript_text": " Tanya Cushman Reviewer Reviewer Hey everybody. Can everybody hear me okay? Pretty good? Alright. Thank you so much for coming here and being here today. So, hello friends. My name is Will Binz. I also go by W Binns. They're smashing my name together. I lead communities at Base. I'm also a full stack developer at Base. We're one and a half year old, layer two on top of Ethereum. Our objective is to build a global open economy that spreads equality, opportunity, and freedom around the world. We just processed our one billionth transaction this past week. It's still day one. And across Discord, Farcaster, GitHub, and X. There's millions of people that are part of our communities. I said hello friends, but we don't know each other. We're different genders, different skin colors. We come from different countries. There's all kinds of things that make us different here, that fracture us, that drive us apart, that lead to a lot of the conflict that we see in this world right now. But we're here. We're here together. All of us here left something behind that really wasn't working so well in some way. To look towards something better for us, for our friends, for our families, for our loved ones. And that, I think, is something that all of us can build a friendship on. And I think that's, in the context of this lightning talk, high level, our future is the most important part, focusing on that in building a scalable community. An open economy that anybody can be part of. Being able to work from wherever you want. Being able to live where you want, equality, all those things I talked about, all those things that make us different, all those things that don't matter, transparency, verifiability on chain, not having to take each other's word for things, freedom, and hopefully, in what we see these days in the future, more peace in the world. But how do we do that? We have to make space for everyone. Builders, creators, lurkers, people that are just curious, speculators, gamers, even scammers and spammers. There should be direct paths for all of these people. And in order to do that, we have to create opportunities for everyone. I just said scammers and spammers. And I think one of the most important parts of creating opportunity for scammers and spammers is being empathetic. There's people that are born just by the lottery of life in some part of the world where they can't even leave their town. They wish that they could get on a plane to come somewhere like this, to sit next to us today, but they can't do that. The opportunities in front of them led them to that path. It's up to us as community builders to build something better, to help people discover new apps, new opportunities, new jobs, learn, educate them. For some people, it's just to make friends, new friends, in a real world where they don't have any. And in all that, all of us, a better life. In order to do that, we have to focus on the fact that these problems in the world, these problems that we have with each other, across this EVM even, these things that make us different, these sub-communities that split us apart, that we see disagreements in, those problems are what unite us. They're not what should drive us apart. This EVM, Ethereum, is what connects us together. And so you as builders, building community, people, building apps across the EVM, across on-chain, an app is just something people download, but a community is something that you come back for. So what do we do? We have to realize and admit our mistakes when we have them. We have to realize we're not kings and queens. We're not royalty. Being in this space is a gift from the universe. But it's also a challenge. What am I? What are we? What are you going to do with this gift to be here today? To be able to fly here to Thailand. To be part of this community when others can't leave their own. To build something better. And there's a quote that's often cliche, but it's so true. Alone, we go fast, but together, we can go far. And so in that vein, I set up just a Telegram group. So anybody here, there's no difference in networks. We're all part of this Ethereum community. If you'd like to be part of this telegram, I'm an open book. People in our base community are open books. We're trying to build a better world together. Let's share our knowledge. Let's build a brain test. People watching this recording later, come to this group. Let's work together. Let's go through the things that we can't talk about in a lightning talk. How do we build safe, secure communities? How do we scale communities? How do we make sure that everybody has their space? So thank you all for sharing your time to be here today. Thank you so much, Will. Thank so much Will. Any questions? Please raise your hand I will throw this cube to you. Oh there's one there? Please help me. It's not a question, but a word of gratitude. Thank you for your talk. Thank you for your time. We highly need this kind of speech in the space like that. I just went out from a very different conversation. Respect. Thank you. Yeah. Thank you. Thank you. I see another question over there. Hi, Will. I saw you in person. How do you see communities like base Latin, base India, base Africa impact those communities? I think that thinking about like how all communities start, they start small. And in time, they grow. Some succeed, some fail, but if we think of things like on a cellular level, how human life imitates itself in the form of how we build communities, the ones that continue to get bigger and bigger and bigger, they divide and become their own communities. Taking Costa Rica as an example here, there's many builders in Costa Rica as an example here. There's many builders in Costa Rica, but in that, there's also many people with differences. There's people that want to build on chain, that just want to play games, they just want to trade, they just want to work on infra. And a lot of those people, they don't want to have anything to do with each other. That doesn't mean they don't like each other, they're just not interested. So for us as community builders, it's important that within the first 10, 15 seconds when they come into our community, we're helping them get to the right place. And so in the context of this question for based LATAM, which we're referring to here, which is based communities in Latin America, it's continuing to build more and more smaller and smaller and smaller communities until eventually we reach the grassroots. So that's my answer to the question.", "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731400200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1AIOGsICQD3wWyrBZ5kDP7FX-hHDQ53lT_n8M7Jdl_kI", + "slot_start": 1731401400000, + "slot_end": 1731402000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Z6KNA8npIjlvXcTWwPrFhWHFQ9A2gd2wkiaNRb-bwuQ", "resources_slides": null, "speakers": [ - "francesco" + "wbnns" ] }, "vector": [ 0, 0, 0, - 0, 6, 0, 0, @@ -655252,7 +655763,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -655417,6 +655927,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -655431,6 +655942,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -655484,7 +655996,6 @@ 2, 0, 0, - 2, 0, 0, 0, @@ -655528,6 +656039,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -655554,7 +656067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -655591,6 +656103,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -655651,7 +656165,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -655981,11 +656494,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -655998,50 +656511,48 @@ }, { "session": { - "id": "searcher-competition-in-block-building", - "sourceId": "MHRYV9", - "title": "Searcher Competition in Block Building", - "description": "We study the amount of MEV captured by validators, as a function of searcher competition. The core is a suitable solution concept in this context that makes robust predictions independent of implementation details or specific mechanisms chosen. The surplus share of validators is a function of searcher competition. Searchers can obtain at most the marginal value increase of the winning block relative to the best block that can be built without them. We validate the theory empirically.", - "track": "Cryptoeconomics", + "id": "scaling-crypto-theres-an-app-for-that-onboarding-millions-in-africa-with-minipay", + "sourceId": "EXCPST", + "title": "Scaling Crypto? There's an App for That. Onboarding Millions in Africa with MiniPay", + "description": "Post-EthCC, everyone’s talking about the industry’s influx of infra & lack of consumer apps. These conversations overlook the strides made in Africa with MiniPay, a self-custodial stablecoin wallet with 3M+ activated accounts since launching less than a year ago. In this panel, Rene, Yoseph & co-panelists will discuss building, scaling, & updating a truly user-friendly crypto wallet, introducing net new users to Web3 and dApps, & the power of ERC-20 stablecoins for payments in emerging markets.", + "track": "Real World Ethereum", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Design", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Cooperative", - "Game", - "Theory;" + "payment", + "p2p finance", + "mobile" ], "tags": [ - "Core Protocol", - "Gaming", - "Mechanism design", - "MEV", - "theory", - "cooperative", - "Core Protocol", - "Mechanism design", - "MEV" + "Protocol Design", + "Scalability", + "UI/UX", + "Mobile", + "Protocol Design", + "Scalability", + "UI/UX" ], "language": "en", "speakers": [ - "akaki-mamageishvili" + "rene-reinsberg" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731649200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1oRDP1vAH4P88oiBLEXOsJco7KgtJbQmYvKAeAkMug6Y" + "slot_start": 1731574800000, + "slot_end": 1731575400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1lk319WDhop2qBsR_BdMLAl1tdzOwri17ao4IPguI7Ac" }, "vector": [ 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -656480,7 +656991,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -656612,6 +657122,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -656775,12 +657286,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -656792,7 +657301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -656800,6 +657308,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -656822,6 +657331,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -656834,6 +657344,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -656884,7 +657395,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -656915,6 +657425,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -657222,7 +657733,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -657250,7 +657760,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -657335,57 +657844,74 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, 0, - 2, 0, 0 ] }, { "session": { - "id": "secondhand-liberalism-a-story-of-microdosing-internet-freedom", - "sourceId": "TB8DG7", - "title": "Secondhand Liberalism: A Story of Microdosing Internet Freedom", - "description": "Liberalism isn't the default. For those growing up in non-Western societies, liberalism is often \"secondhand\"—it's imbued in Western cultural products and present in software and the internet which in turn service liberal ideals. What if it's no longer the case?", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "scaling-ethereum-with-das-an-iterative-approach", + "sourceId": "JFWPRG", + "title": "Scaling Ethereum with DAS: an iterative approach", + "description": "In this time between the launch of 4844 and the possible launch of a first version of PeerDAS, we explore and explain the iterative approach that has been employed in the rollout of blobs and DAS to Ethereum, and discuss the past and future steps.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "afra-zhao-wang" + "tags": [ + "Blobspace", + "Data Availability", + "Ethereum Roadmap", + "Scalability" + ], + "keywords": [ + "PeerDAS" ], + "duration": 1522, + "language": "en", + "sources_swarmHash": "567a45d310dc81275e061b69797f55ce5386ac2d95acdaf5d71076c274539d71", + "sources_youtubeId": "toR2UKzE_zA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731651000000, + "slot_start": 1731398400000, + "slot_end": 1731400200000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1l0E0bgrVT-d4Vqx2zZeLBbCopXsf2glznve9weGlx2U" + "resources_presentation": "https://docs.google.com/presentation/d/1AIOGsICQD3wWyrBZ5kDP7FX-hHDQ53lT_n8M7Jdl_kI", + "resources_slides": null, + "speakers": [ + "francesco" + ] }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -657958,8 +658484,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -658188,8 +658714,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -658259,6 +658787,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -658312,6 +658841,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -658679,9 +659209,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 2, @@ -658696,44 +659226,51 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "securing-grandines-performance", - "sourceId": "GGWXYQ", - "title": "Securing Grandine's Performance", - "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.", - "track": "[CLS] EPF Day", + "id": "searcher-competition-in-block-building", + "sourceId": "MHRYV9", + "title": "Searcher Competition in Block Building", + "description": "We study the amount of MEV captured by validators, as a function of searcher competition. The core is a suitable solution concept in this context that makes robust predictions independent of implementation details or specific mechanisms chosen. The surplus share of validators is a function of searcher competition. Searchers can obtain at most the marginal value increase of the winning block relative to the best block that can be built without them. We validate the theory empirically.", + "track": "Cryptoeconomics", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Design", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Cooperative", + "Game", + "Theory;" + ], "tags": [ - "Consensus", - "Consensus Mechanisms", "Core Protocol", - "Cryptography", - "Security" + "Gaming", + "Mechanism design", + "MEV", + "theory", + "cooperative", + "Core Protocol", + "Mechanism design", + "MEV" ], "language": "en", "speakers": [ - "mercy-boma-naps-nkari", - "zarathustra" + "akaki-mamageishvili" ], "eventId": "devcon-7", - "slot_start": 1731482100000, - "slot_end": 1731483000000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog" + "slot_start": 1731648600000, + "slot_end": 1731649200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1oRDP1vAH4P88oiBLEXOsJco7KgtJbQmYvKAeAkMug6Y" }, "vector": [ 0, 0, + 6, 0, 0, 0, @@ -658747,7 +659284,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -659177,6 +659713,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -659311,8 +659848,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -659470,7 +660005,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -659480,33 +660014,19 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -659598,6 +660118,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -659664,7 +660185,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -659936,6 +660456,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -659963,6 +660484,19 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -660032,7 +660566,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -660049,53 +660582,45 @@ 0, 0, 0, + 0, + 0, + 2, + 0, 0 ] }, { "session": { - "id": "security-frameworks-by-seal", - "sourceId": "A7TNUF", - "title": "Security Frameworks by SEAL", - "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.", - "track": "Security", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "secondhand-liberalism-a-story-of-microdosing-internet-freedom", + "sourceId": "TB8DG7", + "title": "Secondhand Liberalism: A Story of Microdosing Internet Freedom", + "description": "Liberalism isn't the default. For those growing up in non-Western societies, liberalism is often \"secondhand\"—it's imbued in Western cultural products and present in software and the internet which in turn service liberal ideals. What if it's no longer the case?", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Best practices", - "Guidelines", - "Frameworks." - ], - "tags": [ - "Security", - "Hacks", - "Public good", - "framework", - "Hacks", - "Public good", - "Security" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "matta-the-red-guild" + "afra-zhao-wang" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic" + "slot_start": 1731650400000, + "slot_end": 1731651000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1l0E0bgrVT-d4Vqx2zZeLBbCopXsf2glznve9weGlx2U" }, "vector": [ - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -660366,7 +660891,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -660668,6 +661192,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -660827,7 +661352,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -660936,7 +661460,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -660991,7 +661514,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -661078,7 +661600,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -661391,11 +661912,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, 0, 2, 0, @@ -661406,43 +661928,43 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "security-of-fiat-shamir-transformation", - "sourceId": "VMNCS8", - "title": "Security of Fiat-Shamir transformation", - "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k", - "track": "Applied Cryptography", - "type": "Talk", + "id": "securing-grandines-performance", + "sourceId": "GGWXYQ", + "title": "Securing Grandine's Performance", + "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "small fields", - "IOP" - ], + "keywords": [], "tags": [ - "Fiat-Shamir heuristic", - "STARK", - "Security", - "iop", - "Fiat-Shamir heuristic", - "Security", - "STARK" + "Consensus", + "Consensus Mechanisms", + "Core Protocol", + "Cryptography", + "Security" ], "language": "en", "speakers": [ - "michal-zajac" + "mercy-boma-naps-nkari", + "zarathustra" ], "eventId": "devcon-7", - "slot_start": 1731482400000, - "slot_end": 1731484200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY" + "slot_start": 1731482100000, + "slot_end": 1731483000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog" }, "vector": [ 0, @@ -661455,12 +661977,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -662024,9 +662546,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -662188,6 +662711,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -662195,11 +662719,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -662376,6 +662902,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -662394,7 +662921,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -662661,9 +663187,6 @@ 0, 0, 0, - 2, - 2, - 0, 0, 0, 0, @@ -662749,7 +663272,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -662762,54 +663284,45 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "security-through-obscurity-using-microdots-to-store-secrets", - "sourceId": "UHQDPU", - "title": "Security through obscurity. Using microdots to store secrets.", - "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.", + "id": "security-frameworks-by-seal", + "sourceId": "A7TNUF", + "title": "Security Frameworks by SEAL", + "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.", "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Lobby", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, + "keywords": [ + "Best practices", + "Guidelines", + "Frameworks." + ], "tags": [ - "Digital Sovereignty", - "Cryptography", "Security", - "Hardware wallets", - "Custody", - "Cryptography", - "Custody", - "Digital Sovereignty", - "Hardware wallets", + "Hacks", + "Public good", + "framework", + "Hacks", + "Public good", "Security" ], - "keywords": [ - "None" - ], - "duration": 579, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "3mXa1oeHzzA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731406200000, - "slot_end": 1731406800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M", - "resources_slides": null, "speakers": [ - "jseam" - ] + "matta-the-red-guild" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic" }, "vector": [ 6, @@ -663089,6 +663602,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -663394,7 +663909,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -663563,7 +664077,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -663600,7 +664113,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -663661,6 +664173,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -663713,6 +664228,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -663800,6 +664316,63 @@ 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, @@ -663887,7 +664460,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664030,7 +664602,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664057,11 +664628,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -664070,6 +664643,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "security-of-fiat-shamir-transformation", + "sourceId": "VMNCS8", + "title": "Security of Fiat-Shamir transformation", + "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "small fields", + "IOP" + ], + "tags": [ + "Fiat-Shamir heuristic", + "STARK", + "Security", + "iop", + "Fiat-Shamir heuristic", + "Security", + "STARK" + ], + "language": "en", + "speakers": [ + "michal-zajac" + ], + "eventId": "devcon-7", + "slot_start": 1731482400000, + "slot_end": 1731484200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY" + }, + "vector": [ 0, 0, 0, @@ -664080,6 +664692,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -664112,7 +664725,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664129,56 +664741,6 @@ 0, 0, 0, - 2 - ] - }, - { - "session": { - "id": "semaphore-v4", - "sourceId": "ZU9D8U", - "title": "Semaphore V4", - "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Privacy", - "Zero-Knowledge", - "User Experience", - "proof-of", - "membership", - "Privacy", - "User Experience", - "Zero-Knowledge" - ], - "keywords": [ - "semaphore", - "anonymity sets", - "proof of membership" - ], - "duration": 1035, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "OErC2MyIKjY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt", - "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.", - "eventId": "devcon-7", - "slot_start": 1731397200000, - "slot_end": 1731397800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do", - "resources_slides": null, - "speakers": [ - "cedoor" - ] - }, - "vector": [ 0, 0, 0, @@ -664189,7 +664751,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -664702,6 +665263,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -664762,7 +665324,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -664860,6 +665421,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -664929,11 +665491,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -665034,7 +665594,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -665075,6 +665634,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -665287,7 +665847,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -665340,6 +665899,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -665398,7 +665959,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -665423,10 +665983,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -665438,6 +666000,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "security-through-obscurity-using-microdots-to-store-secrets", + "sourceId": "UHQDPU", + "title": "Security through obscurity. Using microdots to store secrets.", + "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Lobby", + "featured": false, + "doNotRecord": false, + "tags": [ + "Digital Sovereignty", + "Cryptography", + "Security", + "Hardware wallets", + "Custody", + "Cryptography", + "Custody", + "Digital Sovereignty", + "Hardware wallets", + "Security" + ], + "keywords": [ + "None" + ], + "duration": 579, + "language": "en", + "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52", + "sources_youtubeId": "3mXa1oeHzzA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731406200000, + "slot_end": 1731406800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M", + "resources_slides": null, + "speakers": [ + "jseam" + ] + }, + "vector": [ + 6, 0, 0, 0, @@ -665479,11 +666092,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -665496,38 +666107,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "shadow-network-simulations", - "sourceId": "H7HCJJ", - "title": "Shadow Network Simulations", - "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Core Protocol", - "Layer 1", - "Testing" - ], - "language": "en", - "speakers": [ - "daniel-knopik" - ], - "eventId": "devcon-7", - "slot_start": 1731485700000, - "slot_end": 1731486600000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY" - }, - "vector": [ 0, 0, 0, @@ -665543,7 +666122,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -666054,6 +666632,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666112,7 +666691,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -666211,6 +666789,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666223,6 +666802,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666259,6 +666839,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -666281,11 +666862,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -666508,7 +667087,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -666548,6 +667126,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -666687,6 +667269,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -666768,6 +667351,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -666784,6 +667368,56 @@ 0, 0, 0, + 2 + ] + }, + { + "session": { + "id": "semaphore-v4", + "sourceId": "ZU9D8U", + "title": "Semaphore V4", + "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Privacy", + "Zero-Knowledge", + "User Experience", + "proof-of", + "membership", + "Privacy", + "User Experience", + "Zero-Knowledge" + ], + "keywords": [ + "semaphore", + "anonymity sets", + "proof of membership" + ], + "duration": 1035, + "language": "en", + "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691", + "sources_youtubeId": "OErC2MyIKjY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt", + "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.", + "eventId": "devcon-7", + "slot_start": 1731397200000, + "slot_end": 1731397800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do", + "resources_slides": null, + "speakers": [ + "cedoor" + ] + }, + "vector": [ 0, 0, 0, @@ -666794,6 +667428,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666828,71 +667463,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "simulating-an-ethereum-network-at-scale", - "sourceId": "FAZBAD", - "title": "Simulating an Ethereum network at scale", - "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Networking", - "Simulation" - ], - "tags": [ - "Layer 1", - "simulation", - "Layer", - "1" - ], - "language": "en", - "speakers": [ - "pop", - "daniel-knopik" - ], - "eventId": "devcon-7", - "slot_start": 1731564600000, - "slot_end": 1731566400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -667431,42 +668001,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, 6, 0, 0, @@ -667639,6 +668173,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -667698,7 +668233,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -667740,6 +668274,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -667992,6 +668527,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -668182,6 +668718,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -668204,35 +668741,31 @@ }, { "session": { - "id": "simulating-economic-systems-of-an-autonomous-world", - "sourceId": "KWKW3W", - "title": "Simulating Economic Systems of an Autonomous World", - "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", + "id": "shadow-network-simulations", + "sourceId": "H7HCJJ", + "title": "Shadow Network Simulations", + "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Token Engineering", - "Simulations", - "Complex Systems" - ], + "keywords": [], "tags": [ - "Autonomous World", - "Gaming", - "Protocol Design" + "Core Protocol", + "Layer 1", + "Testing" ], "language": "en", "speakers": [ - "nico-rodriguez" + "daniel-knopik" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk" + "slot_start": 1731485700000, + "slot_end": 1731486600000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY" }, "vector": [ 0, @@ -668247,10 +668780,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -668395,7 +668928,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -668820,6 +669352,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -668988,9 +669522,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -669019,7 +669555,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -669083,8 +669618,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -669217,6 +669750,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -669557,32 +670091,38 @@ }, { "session": { - "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje", - "sourceId": "R9KTR7", - "title": "Singer sing writer hour with adegbengaoggunbdeje", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "simulating-an-ethereum-network-at-scale", + "sourceId": "FAZBAD", + "title": "Simulating an Ethereum network at scale", + "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Networking", + "Simulation" + ], + "tags": [ + "Layer 1", + "simulation", + "Layer", + "1" + ], "language": "en", - "speakers": [], + "speakers": [ + "pop", + "daniel-knopik" + ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731474000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE" + "slot_start": 1731564600000, + "slot_end": 1731566400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ" }, "vector": [ - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -670167,6 +670707,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -670335,6 +670877,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -670397,6 +670940,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -670800,6 +671344,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -670882,6 +671427,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -670900,50 +671446,41 @@ }, { "session": { - "id": "single-slot-finality-and-the-future-of-staking", - "sourceId": "LZCP8E", - "title": "Single Slot Finality and the future of staking", - "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3", - "track": "Core Protocol", + "id": "simulating-economic-systems-of-an-autonomous-world", + "sourceId": "KWKW3W", + "title": "Simulating Economic Systems of an Autonomous World", + "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Economic", - "security" + "Token Engineering", + "Simulations", + "Complex Systems" ], "tags": [ - "Core Protocol", - "Ethereum Roadmap", - "Home staking", - "Single-slot Finality", - "Consensus Mechanisms", - "Security", - "economy", - "Consensus Mechanisms", - "Core Protocol", - "Ethereum Roadmap", - "Home staking", - "Single-slot Finality" + "Autonomous World", + "Gaming", + "Protocol Design" ], "language": "en", "speakers": [ - "francesco" + "nico-rodriguez" ], "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731575400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI" + "slot_start": 1731577800000, + "slot_end": 1731579300000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -670952,6 +671489,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -671099,6 +671637,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -671516,7 +672055,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -671677,7 +672215,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -671696,7 +672233,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671726,6 +672262,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -671754,7 +672291,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671763,7 +672299,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671791,6 +672326,13 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -671871,7 +672413,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671914,7 +672455,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -672061,7 +672601,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -672261,50 +672800,41 @@ }, { "session": { - "id": "slangs-query-api-a-better-way-to-analyse-solidity-code", - "sourceId": "8PYLB7", - "title": "Slang’s Query API: a better way to analyse Solidity code", - "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Expert", + "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje", + "sourceId": "R9KTR7", + "title": "Singer sing writer hour with adegbengaoggunbdeje", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Parsing", - "Compiling" - ], - "tags": [ - "Developer Infrastructure", - "Tooling", - "Languages", - "compilers", - "Developer Infrastructure", - "Languages", - "Tooling" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "antony-blakey" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731650400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo" + "slot_start": 1731470400000, + "slot_end": 1731474000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -672881,7 +673411,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -673054,7 +673583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -673087,7 +673615,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -673130,7 +673657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -673262,7 +673788,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -673599,6 +674124,8 @@ 0, 0, 2, + 0, + 0, 2, 0, 0, @@ -673617,38 +674144,50 @@ }, { "session": { - "id": "small-brain-games-mud-day-demo", - "sourceId": "9ZBKKS", - "title": "Small Brain Games - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "single-slot-finality-and-the-future-of-staking", + "sourceId": "LZCP8E", + "title": "Single Slot Finality and the future of staking", + "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Economic", + "security" + ], "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" + "Core Protocol", + "Ethereum Roadmap", + "Home staking", + "Single-slot Finality", + "Consensus Mechanisms", + "Security", + "economy", + "Consensus Mechanisms", + "Core Protocol", + "Ethereum Roadmap", + "Home staking", + "Single-slot Finality" ], "language": "en", "speakers": [ - "small-brain" + "francesco" ], "eventId": "devcon-7", - "slot_start": 1731557700000, - "slot_end": 1731558000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8" + "slot_start": 1731573600000, + "slot_end": 1731575400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -673657,9 +674196,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -673787,7 +674323,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -674225,6 +674760,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -674386,6 +674922,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -674404,6 +674941,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -674461,6 +674999,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -674469,6 +675008,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -674493,8 +675033,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -674578,7 +675116,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -674766,6 +675306,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -674943,6 +675484,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -674953,9 +675495,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -674967,45 +675506,49 @@ }, { "session": { - "id": "smart-accounts-need-smart-sessions", - "sourceId": "SJDY99", - "title": "Smart Accounts need Smart Sessions", - "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.", - "track": "Usability", + "id": "slangs-query-api-a-better-way-to-analyse-solidity-code", + "sourceId": "8PYLB7", + "title": "Slang’s Query API: a better way to analyse Solidity code", + "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.", + "track": "Developer Experience", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "standards", - "wallets", - "interoperability" + "Parsing", + "Compiling" ], "tags": [ - "interoperability" + "Developer Infrastructure", + "Tooling", + "Languages", + "compilers", + "Developer Infrastructure", + "Languages", + "Tooling" ], "language": "en", "speakers": [ - "pedro-gomes" + "antony-blakey" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM" + "slot_start": 1731648600000, + "slot_end": 1731650400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -675757,6 +676300,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -675789,6 +676333,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -675831,6 +676376,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -675964,6 +676510,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -676126,8 +676673,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -676296,11 +676841,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -676318,39 +676863,40 @@ }, { "session": { - "id": "smart-contracts-with-privacy-case-study-buying-renewable-power", - "sourceId": "F9PWUP", - "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power", - "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Business", + "id": "small-brain-games-mud-day-demo", + "sourceId": "9ZBKKS", + "title": "Small Brain Games - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Enterprise" - ], + "keywords": [], "tags": [ - "Privacy", - "Zero-Knowledge", - "Use Cases", - "enterprise", - "Privacy", - "Use Cases", - "Zero-Knowledge" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "paul-brody" + "small-brain" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8" + "slot_start": 1731557700000, + "slot_end": 1731558000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -676487,6 +677033,13 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -676939,7 +677492,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -677101,7 +677653,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -677168,6 +677719,28 @@ 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, @@ -677206,7 +677779,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -677572,44 +678144,15 @@ 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, @@ -677657,7 +678200,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -677667,48 +678209,38 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements", - "sourceId": "SFY3FB", - "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements", - "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "smart-accounts-need-smart-sessions", + "sourceId": "SJDY99", + "title": "Smart Accounts need Smart Sessions", + "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Lunarpunk", - "Culture" + "standards", + "wallets", + "interoperability" ], "tags": [ - "Coordination", - "Anonymity", - "Solarpunk", - "Ethereum for Good", - "Social", - "culture", - "Anonymity", - "Coordination", - "Ethereum for Good", - "Social", - "Solarpunk" + "interoperability" ], "language": "en", "speakers": [ - "manualzuru" + "pedro-gomes" ], "eventId": "devcon-7", - "slot_start": 1731496800000, - "slot_end": 1731497400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o" + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM" }, "vector": [ 0, @@ -677716,6 +678248,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -678295,12 +678830,13 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -678475,7 +679011,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -678574,8 +679109,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -678604,7 +679137,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -678629,7 +679161,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -678684,7 +679215,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -678844,6 +679374,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -679017,10 +679548,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -679033,44 +679566,46 @@ }, { "session": { - "id": "solidity-inline-assembly-for-developer-experience", - "sourceId": "F7XJZW", - "title": "Solidity Inline-Assembly for Developer Experience", - "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.", - "track": "Developer Experience", + "id": "smart-contracts-with-privacy-case-study-buying-renewable-power", + "sourceId": "F9PWUP", + "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power", + "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!", + "track": "Real World Ethereum", "type": "Talk", "expertise": "Intermediate", - "audience": "Developper", + "audience": "Business", "featured": false, "doNotRecord": false, "keywords": [ - "Solidity" + "Enterprise" ], "tags": [ - "Gas", - "Account Abstraction", - "solidity", - "Account Abstraction", - "Gas" + "Privacy", + "Zero-Knowledge", + "Use Cases", + "enterprise", + "Privacy", + "Use Cases", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "vectorized" + "paul-brody" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k" + "slot_start": 1731493800000, + "slot_end": 1731495600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -679652,9 +680187,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -679815,6 +680350,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -679853,7 +680389,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -679882,6 +680417,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -679919,6 +680455,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -680030,7 +680567,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -680166,7 +680702,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -680286,6 +680821,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -680371,12 +680907,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -680386,46 +680922,50 @@ }, { "session": { - "id": "solidity-then-now-and-the-future", - "sourceId": "HZ3DEF", - "title": "Solidity: Then, Now, & the Future!", - "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements", + "sourceId": "SFY3FB", + "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements", + "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Smart Contract Development", - "Solidity" + "Lunarpunk", + "Culture" ], "tags": [ - "Tooling", - "Languages", - "solidity", - "Languages", - "Tooling" + "Coordination", + "Anonymity", + "Solarpunk", + "Ethereum for Good", + "Social", + "culture", + "Anonymity", + "Coordination", + "Ethereum for Good", + "Social", + "Solarpunk" ], "language": "en", "speakers": [ - "vishwa-mehta" + "manualzuru" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA" + "slot_start": 1731496800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o" }, "vector": [ 0, 0, 0, - 6, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -681177,8 +681717,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -681187,6 +681725,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681253,7 +681792,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681286,6 +681824,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -681314,6 +681854,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681338,6 +681879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681394,6 +681936,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681520,7 +682063,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681718,7 +682260,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681729,6 +682270,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -681740,44 +682283,40 @@ }, { "session": { - "id": "solo-staking-in-the-dark-forest-a-survival-guide", - "sourceId": "REJ3SW", - "title": "Solo staking in the dark forest: a survival guide", - "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", + "id": "solidity-inline-assembly-for-developer-experience", + "sourceId": "F7XJZW", + "title": "Solidity Inline-Assembly for Developer Experience", + "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "Metadata" + "Solidity" ], "tags": [ - "Staking", - "Privacy", - "Security", - "MEV", - "metadata", - "MEV", - "Privacy", - "Security" + "Gas", + "Account Abstraction", + "solidity", + "Account Abstraction", + "Gas" ], "language": "en", "speakers": [ - "qianchen-q-yu" + "vectorized" ], "eventId": "devcon-7", - "slot_start": 1731639900000, - "slot_end": 1731640500000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg" + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k" }, "vector": [ 0, 0, 0, - 0, 6, 0, 0, @@ -682365,7 +682904,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -682512,9 +683050,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -682568,6 +683104,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -682629,7 +683166,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -682641,7 +683177,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -682748,6 +683283,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -682881,6 +683417,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -682996,7 +683536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683084,11 +683623,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0 @@ -683096,41 +683637,36 @@ }, { "session": { - "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem", - "sourceId": "QKRCF7", - "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem", - "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.", + "id": "solidity-then-now-and-the-future", + "sourceId": "HZ3DEF", + "title": "Solidity: Then, Now, & the Future!", + "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap", "track": "Developer Experience", "type": "Talk", "expertise": "Intermediate", - "audience": "Developper", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "DeFi", - "Cross-chain", - "Aggregation" + "Smart Contract Development", + "Solidity" ], "tags": [ - "Fragmentation", - "UI/UX", - "Account Abstraction", - "defi", - "cross-chain", - "aggregation", - "Account Abstraction", - "Fragmentation", - "UI/UX" + "Tooling", + "Languages", + "solidity", + "Languages", + "Tooling" ], "language": "en", "speakers": [ - "sunny-aggarwal" + "vishwa-mehta" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA" }, "vector": [ 0, @@ -683724,9 +684260,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -683893,6 +684429,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -683914,7 +684452,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683922,7 +684459,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683930,7 +684466,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683970,6 +684505,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -684064,7 +684600,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684237,6 +684772,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -684347,7 +684886,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684356,7 +684894,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684437,6 +684974,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -684445,7 +684983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684455,47 +684992,44 @@ }, { "session": { - "id": "sovereignists-vs-globalists", - "sourceId": "ZHQPKA", - "title": "Sovereignists vs. Globalists", - "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to", - "track": "Cypherpunk & Privacy", + "id": "solo-staking-in-the-dark-forest-a-survival-guide", + "sourceId": "REJ3SW", + "title": "Solo staking in the dark forest: a survival guide", + "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.", + "track": "Core Protocol", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Vision", - "future", - "resilient technologies" + "Metadata" ], "tags": [ - "Decentralization Improvements", - "Digital Sovereignty", - "Emergency Plan", - "resiliency", - "technology", - "Decentralization Improvements", - "Digital Sovereignty", - "Emergency Plan" + "Staking", + "Privacy", + "Security", + "MEV", + "metadata", + "MEV", + "Privacy", + "Security" ], "language": "en", "speakers": [ - "adrian-brink" + "qianchen-q-yu" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731649200000, + "slot_start": 1731639900000, + "slot_end": 1731640500000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw" + "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg" }, "vector": [ 0, 0, 0, 0, - 0, 6, 0, 0, @@ -685084,7 +685618,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -685232,10 +685765,13 @@ 0, 0, 0, + 6, + 0, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -685279,7 +685815,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -685347,6 +685882,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -685358,6 +685894,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -685390,7 +685928,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -685433,7 +685970,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -685615,7 +686151,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -685714,6 +686249,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -685800,8 +686336,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -685813,47 +686349,51 @@ }, { "session": { - "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels", - "sourceId": "L3Z78Q", - "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels", - "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Hobby", + "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem", + "sourceId": "QKRCF7", + "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem", + "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "ELI5" + "DeFi", + "Cross-chain", + "Aggregation" ], "tags": [ - "Layer 2s", - "Scalability", - "ZK-EVMs", - "eli5", - "Layer 2s", - "Scalability", - "ZK-EVMs" + "Fragmentation", + "UI/UX", + "Account Abstraction", + "defi", + "cross-chain", + "aggregation", + "Account Abstraction", + "Fragmentation", + "UI/UX" ], "language": "en", "speakers": [ - "emily" + "sunny-aggarwal" ], "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731394800000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8" + "slot_start": 1731577800000, + "slot_end": 1731579600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -686439,9 +686979,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -686628,6 +687168,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -686635,6 +687176,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -686642,6 +687184,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -686650,7 +687193,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -686724,7 +687266,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -686777,6 +687318,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -686932,7 +687474,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -686992,7 +687533,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687061,6 +687601,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -687069,6 +687610,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -687145,10 +687687,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -687162,39 +687704,45 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "speedrunning-chain-abstraction-eips", - "sourceId": "UVUPRS", - "title": "Speedrunning chain abstraction EIPs", - "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.", - "track": "Usability", - "type": "Workshop", - "expertise": "Expert", - "audience": "Developer", - "featured": true, + "id": "sovereignists-vs-globalists", + "sourceId": "ZHQPKA", + "title": "Sovereignists vs. Globalists", + "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, "doNotRecord": false, "keywords": [ - "ChainAbstraction", - "CredibleAccounts", - "Cross-chain" + "Vision", + "future", + "resilient technologies" ], "tags": [ - "cross-chain" + "Decentralization Improvements", + "Digital Sovereignty", + "Emergency Plan", + "resiliency", + "technology", + "Decentralization Improvements", + "Digital Sovereignty", + "Emergency Plan" ], "language": "en", "speakers": [ - "ankit-chiplunkar" + "adrian-brink" ], "eventId": "devcon-7", - "slot_start": 1731655200000, - "slot_end": 1731660600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk" + "slot_start": 1731648600000, + "slot_end": 1731649200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw" }, "vector": [ 0, @@ -687202,10 +687750,11 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -687790,10 +688339,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -687937,6 +688490,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -687973,6 +688534,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -688080,6 +688645,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -688123,6 +688690,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -688302,6 +688870,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -688411,23 +688980,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -688496,11 +689048,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 2, @@ -688511,42 +689063,42 @@ 0, 0, 0, - 0, - 0, - 0, 0 ] }, { "session": { - "id": "sszb-a-high-performance-ssz-implementation-in-rust", - "sourceId": "M3SK39", - "title": "Sszb: A High Performance SSZ Implementation in Rust", - "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem", - "track": "[CLS] EPF Day", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels", + "sourceId": "L3Z78Q", + "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels", + "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Hobby", "featured": false, "doNotRecord": false, "keywords": [ - "serialization", - "ssz", - "rust" + "ELI5" ], "tags": [ - "Core", - "Protocol" + "Layer 2s", + "Scalability", + "ZK-EVMs", + "eli5", + "Layer 2s", + "Scalability", + "ZK-EVMs" ], "language": "en", "speakers": [ - "ghilia-weldesselasie" + "emily" ], "eventId": "devcon-7", - "slot_start": 1731487500000, - "slot_end": 1731488400000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I" + "slot_start": 1731389400000, + "slot_end": 1731394800000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8" }, "vector": [ 0, @@ -688556,6 +689108,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -688564,9 +689117,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -689356,6 +689906,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689429,6 +689980,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689591,8 +690143,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -689638,6 +690188,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689697,6 +690248,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689849,7 +690401,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -689862,6 +690413,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -689871,37 +690424,33 @@ }, { "session": { - "id": "stablecoin-technicalities-innovations-challenges-and-opportunities", - "sourceId": "XJBYKJ", - "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities", - "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, + "id": "speedrunning-chain-abstraction-eips", + "sourceId": "UVUPRS", + "title": "Speedrunning chain abstraction EIPs", + "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.", + "track": "Usability", + "type": "Workshop", + "expertise": "Expert", + "audience": "Developer", + "featured": true, "doNotRecord": false, "keywords": [ - "Stablecoins" + "ChainAbstraction", + "CredibleAccounts", + "Cross-chain" ], "tags": [ - "Use Cases", - "Remittance", - "Product-market fit", - "stablecoin", - "Product-market fit", - "Remittance", - "Use Cases" + "cross-chain" ], "language": "en", "speakers": [ - "edwin-aoki" + "ankit-chiplunkar" ], "eventId": "devcon-7", - "slot_start": 1731568200000, - "slot_end": 1731568800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M" + "slot_start": 1731655200000, + "slot_end": 1731660600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk" }, "vector": [ 0, @@ -689910,6 +690459,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -690498,11 +691049,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -690700,7 +691252,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -690721,7 +691272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -691007,7 +691557,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -691097,7 +691646,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -691120,6 +691668,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -691204,13 +691754,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, 0, 0, 0, @@ -691226,48 +691776,40 @@ }, { "session": { - "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards", - "sourceId": "J3SWYT", - "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards", - "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.", - "track": "Core Protocol", + "id": "sszb-a-high-performance-ssz-implementation-in-rust", + "sourceId": "M3SK39", + "title": "Sszb: A High Performance SSZ Implementation in Rust", + "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem", + "track": "[CLS] EPF Day", "type": "Talk", "expertise": "Intermediate", - "audience": "Stakers/Validators", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "node running", - "RISC-V", - "Hardware optimization" + "serialization", + "ssz", + "rust" ], "tags": [ - "Validator Experience", - "Home staking", - "Decentralization", - "optimization", - "hardware", - "Decentralization", - "Home staking", - "Validator Experience" + "Core", + "Protocol" ], "language": "en", "speakers": [ - "aavegotch1eth", - "haurog" + "ghilia-weldesselasie" ], "eventId": "devcon-7", - "slot_start": 1731571800000, - "slot_end": 1731573600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0" + "slot_start": 1731487500000, + "slot_end": 1731488400000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -691279,6 +691821,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -691858,12 +692403,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -692039,7 +692583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -692087,7 +692630,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -692103,7 +692645,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -692180,7 +692721,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -692310,6 +692850,11 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -692350,7 +692895,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -692567,13 +693111,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -692585,46 +693129,37 @@ }, { "session": { - "id": "stark-proofs-eli5", - "sourceId": "BKTYWY", - "title": "STARK proofs ELI5", - "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work", - "track": "Applied Cryptography", + "id": "stablecoin-technicalities-innovations-challenges-and-opportunities", + "sourceId": "XJBYKJ", + "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities", + "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "ZKP", - "Use cases of cryptography", - "STARK", - "eli5", - "STARK", - "Use cases of cryptography", - "ZKP" - ], "keywords": [ - "ELI5" + "Stablecoins" + ], + "tags": [ + "Use Cases", + "Remittance", + "Product-market fit", + "stablecoin", + "Product-market fit", + "Remittance", + "Use Cases" ], - "duration": 496, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "eHPp8mFCS6E", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt", - "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.", + "speakers": [ + "edwin-aoki" + ], "eventId": "devcon-7", - "slot_start": 1731394200000, - "slot_end": 1731394800000, + "slot_start": 1731568200000, + "slot_end": 1731568800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco", - "resources_slides": null, - "speakers": [ - "henri" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M" }, "vector": [ 0, @@ -692633,10 +693168,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -693228,16 +693759,8 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, + 6, 0, 0, 0, @@ -693393,7 +693916,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -693437,10 +693959,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -693458,6 +693980,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -693576,7 +694099,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -693744,6 +694266,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -693773,7 +694296,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -693834,6 +694356,20 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -693949,45 +694485,48 @@ }, { "session": { - "id": "start-contributing-to-economic-protocol-development", - "sourceId": "CEZPBS", - "title": "Start contributing to economic protocol development", - "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards", + "sourceId": "J3SWYT", + "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards", + "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Introduction" + "node running", + "RISC-V", + "Hardware optimization" ], "tags": [ - "Core Protocol", - "Economics", - "introduction", - "Core Protocol", - "Economics" + "Validator Experience", + "Home staking", + "Decentralization", + "optimization", + "hardware", + "Decentralization", + "Home staking", + "Validator Experience" ], "language": "en", "speakers": [ - "julian-ma" + "aavegotch1eth", + "haurog" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731485400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M" + "slot_start": 1731571800000, + "slot_end": 1731573600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0" }, "vector": [ - 0, - 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -694583,6 +695122,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -694737,7 +695277,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -694753,8 +695292,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -694762,6 +695299,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -694809,6 +695347,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -694824,6 +695363,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -694900,6 +695440,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -695069,6 +695610,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -695204,7 +695746,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -695285,7 +695826,6 @@ 2, 0, 0, - 2, 0, 0, 0, @@ -695293,6 +695833,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -695302,53 +695845,59 @@ }, { "session": { - "id": "state-contention-rules-everything-around-me", - "sourceId": "XGHU89", - "title": "State Contention Rules Everything Around Me", - "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", + "id": "stark-proofs-eli5", + "sourceId": "BKTYWY", + "title": "STARK proofs ELI5", + "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Synchronization", - "Concurrency" - ], "tags": [ - "Layer 1", - "Architecture", - "Cross-L2", - "concurrency", - "Architecture", - "Cross-L2", - "Layer 1" + "ZKP", + "Use cases of cryptography", + "STARK", + "eli5", + "STARK", + "Use cases of cryptography", + "ZKP" ], - "language": "en", - "speakers": [ - "james-prestwich" + "keywords": [ + "ELI5" ], + "duration": 496, + "language": "en", + "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161", + "sources_youtubeId": "eHPp8mFCS6E", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt", + "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.", "eventId": "devcon-7", - "slot_start": 1731579000000, - "slot_end": 1731580800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40" + "slot_start": 1731394200000, + "slot_end": 1731394800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco", + "resources_slides": null, + "speakers": [ + "henri" + ] }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -696089,7 +696638,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -696106,6 +696654,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -696136,7 +696685,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -696153,6 +696701,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -696224,7 +696773,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -696274,7 +696822,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -696292,6 +696839,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -696486,6 +697034,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -696640,6 +697189,9 @@ 0, 0, 2, + 0, + 0, + 0, 2, 0, 0, @@ -696658,46 +697210,45 @@ }, { "session": { - "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm", - "sourceId": "VDFBMT", - "title": "State Minimized Layer-2s and Why Ethereum > EVM", - "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.", - "track": "Layer 2", + "id": "start-contributing-to-economic-protocol-development", + "sourceId": "CEZPBS", + "title": "Start contributing to economic protocol development", + "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.", + "track": "Cryptoeconomics", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "node-requirements" + "Introduction" ], "tags": [ - "Network State", - "node-requirements", - "Network", - "State" + "Core Protocol", + "Economics", + "introduction", + "Core Protocol", + "Economics" ], "language": "en", "speakers": [ - "nick-dodson" + "julian-ma" ], "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM" + "slot_start": 1731484800000, + "slot_end": 1731485400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -697448,6 +697999,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -697463,6 +698015,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -697473,7 +698027,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -697913,8 +698466,6 @@ 0, 0, 0, - 2, - 2, 2, 0, 0, @@ -697988,13 +698539,16 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -698010,45 +698564,44 @@ }, { "session": { - "id": "state-of-the-ens", - "sourceId": "VBSW3N", - "title": "State of the ENS", - "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.", - "track": "Real World Ethereum", + "id": "state-contention-rules-everything-around-me", + "sourceId": "XGHU89", + "title": "State Contention Rules Everything Around Me", + "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Beginner", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Usability" + "Synchronization", + "Concurrency" ], "tags": [ - "Protocol Design", - "Identity", - "Public good", - "usability", - "Identity", - "Protocol Design", - "Public good" + "Layer 1", + "Architecture", + "Cross-L2", + "concurrency", + "Architecture", + "Cross-L2", + "Layer 1" ], "language": "en", "speakers": [ - "jeff-lau" + "james-prestwich" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw" + "slot_start": 1731579000000, + "slot_end": 1731580800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40" }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -698799,6 +699352,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -698827,10 +699383,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -698845,6 +699399,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -698890,7 +699447,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -698931,6 +699487,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -698979,6 +699539,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -699271,13 +699835,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -699346,7 +699903,6 @@ 0, 0, 2, - 0, 2, 0, 0, @@ -699365,25 +699921,34 @@ }, { "session": { - "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls", - "sourceId": "KVDNNN", - "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)", - "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", + "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm", + "sourceId": "VDFBMT", + "title": "State Minimized Layer-2s and Why Ethereum > EVM", + "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "node-requirements" + ], + "tags": [ + "Network State", + "node-requirements", + "Network", + "State" + ], "language": "en", - "speakers": [], + "speakers": [ + "nick-dodson" + ], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731653100000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0" + "slot_start": 1731582600000, + "slot_end": 1731583200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM" }, "vector": [ 0, @@ -699393,8 +699958,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -699992,6 +700555,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -700173,6 +700737,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -700612,9 +701177,9 @@ 0, 0, 0, - 0, - 0, - 0, + 2, + 2, + 2, 0, 0, 0, @@ -700690,6 +701255,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -700708,39 +701274,37 @@ }, { "session": { - "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations", - "sourceId": "MVJFDX", - "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations", - "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Product", + "id": "state-of-the-ens", + "sourceId": "VBSW3N", + "title": "State of the ENS", + "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Legal" + "Usability" ], "tags": [ - "Frameworks", - "Privacy", - "Censorship Resistance", - "legal", - "Censorship Resistance", - "Frameworks", - "Privacy" + "Protocol Design", + "Identity", + "Public good", + "usability", + "Identity", + "Protocol Design", + "Public good" ], "language": "en", "speakers": [ - "fatemeh-fannizadeh", - "andre-omietanski", - "amal-ibraymi" + "jeff-lau" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731582000000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA" + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw" }, "vector": [ 0, @@ -700748,8 +701312,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -701265,7 +701829,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -701350,7 +701913,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -701530,8 +702092,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -701586,19 +702150,20 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -701629,7 +702194,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -702043,15 +702607,16 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -702065,40 +702630,34 @@ }, { "session": { - "id": "superliquid-mechanisms-for-decentralized-stablecoins", - "sourceId": "SLNQ8K", - "title": "Superliquid Mechanisms for Decentralized Stablecoins", - "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", + "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls", + "sourceId": "KVDNNN", + "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)", + "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Stablecoins", - "DeFi" - ], - "tags": [ - "Mechanism design", - "Economics", - "AMMs", - "defi", - "AMMs", - "Economics", - "Mechanism design" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "ariah-klages-mundt" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU" + "slot_start": 1731650400000, + "slot_end": 1731653100000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 6, @@ -702590,7 +703149,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -702844,7 +703402,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -702872,7 +703429,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -702920,7 +703476,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -703030,7 +703585,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -703402,7 +703956,6 @@ 2, 0, 0, - 0, 2, 0, 0, @@ -703421,48 +703974,46 @@ }, { "session": { - "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware", - "sourceId": "W3DKPQ", - "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware", - "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.", - "track": "Core Protocol", + "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations", + "sourceId": "MVJFDX", + "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations", + "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.", + "track": "Cypherpunk & Privacy", "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Product", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Node Operation", - "Low-Power Hardware" + "Legal" ], "tags": [ - "Layer 1", - "Decentralization Improvements", - "Layer 2s", - "Decentralization", - "hardware", - "low-power", - "Decentralization", - "Decentralization Improvements", - "Layer 1", - "Layer 2s" + "Frameworks", + "Privacy", + "Censorship Resistance", + "legal", + "Censorship Resistance", + "Frameworks", + "Privacy" ], "language": "en", "speakers": [ - "diego-losada", - "fernando-collado" + "fatemeh-fannizadeh", + "andre-omietanski", + "amal-ibraymi" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731477600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ" + "slot_start": 1731576600000, + "slot_end": 1731582000000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA" }, "vector": [ 0, 0, 0, 0, + 0, 6, 0, 0, @@ -703755,7 +704306,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -703981,6 +704531,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -704063,11 +704615,16 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -704203,7 +704760,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -704212,7 +704768,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -704263,7 +704818,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -704311,6 +704865,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -704339,6 +704896,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -704376,7 +704934,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -704682,6 +705239,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -704689,24 +705262,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, @@ -704755,13 +705310,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 2, 0, @@ -704772,48 +705327,43 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 0 ] }, { "session": { - "id": "sybil-proof-mechanisms", - "sourceId": "7QENZH", - "title": "Sybil-Proof Mechanisms", - "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.", + "id": "superliquid-mechanisms-for-decentralized-stablecoins", + "sourceId": "SLNQ8K", + "title": "Superliquid Mechanisms for Decentralized Stablecoins", + "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.", "track": "Cryptoeconomics", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "APS" + "Stablecoins", + "DeFi" ], "tags": [ - "PBS", - "Mechanism design", - "Game Theory", - "MEV", - "apps", - "Game Theory", "Mechanism design", - "MEV", - "PBS" + "Economics", + "AMMs", + "defi", + "AMMs", + "Economics", + "Mechanism design" ], "language": "en", "speakers": [ - "christoph-schlegel" + "ariah-klages-mundt" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731487200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU" }, "vector": [ 0, @@ -705015,7 +705565,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -705308,6 +705857,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -705556,12 +706108,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 6, 0, 0, @@ -705590,10 +706140,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -705638,6 +706188,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -705747,6 +706298,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -706047,7 +706599,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -706120,7 +706671,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -706133,37 +706683,50 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "synthetic-melodies-a-digital-soundscape", - "sourceId": "EZ3EVX", - "title": "Synthetic Melodies: A Digital Soundscape", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware", + "sourceId": "W3DKPQ", + "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware", + "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Node Operation", + "Low-Power Hardware" + ], + "tags": [ + "Layer 1", + "Decentralization Improvements", + "Layer 2s", + "Decentralization", + "hardware", + "low-power", + "Decentralization", + "Decentralization Improvements", + "Layer 1", + "Layer 2s" + ], "language": "en", - "speakers": [], + "speakers": [ + "diego-losada", + "fernando-collado" + ], "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731405600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg" + "slot_start": 1731472200000, + "slot_end": 1731477600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ" }, "vector": [ - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -706460,6 +707023,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -706771,6 +707335,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -706907,6 +707472,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -706915,6 +707481,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -706965,6 +707532,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -707000,6 +707568,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -707076,6 +707645,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -707388,7 +707958,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -707462,7 +708032,6 @@ 0, 2, 0, - 0, 2, 0, 0, @@ -707481,29 +708050,44 @@ }, { "session": { - "id": "synto-nikka", - "sourceId": "ZBSJDY", - "title": "Synto Nikka", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "sybil-proof-mechanisms", + "sourceId": "7QENZH", + "title": "Sybil-Proof Mechanisms", + "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "APS" + ], + "tags": [ + "PBS", + "Mechanism design", + "Game Theory", + "MEV", + "apps", + "Game Theory", + "Mechanism design", + "MEV", + "PBS" + ], "language": "en", - "speakers": [], + "speakers": [ + "christoph-schlegel" + ], "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731497400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic" + "slot_start": 1731486600000, + "slot_end": 1731487200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA" }, "vector": [ 0, 0, + 6, 0, 0, 0, @@ -707511,11 +708095,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -707705,6 +708284,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -708246,10 +708826,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -708280,6 +708863,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -708733,6 +709317,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -708801,9 +709386,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 2, @@ -708818,46 +709403,30 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance", - "sourceId": "QKMVPC", - "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance", - "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Local/SEA", + "id": "synthetic-melodies-a-digital-soundscape", + "sourceId": "EZ3EVX", + "title": "Synthetic Melodies: A Digital Soundscape", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Population Decline", - "Local Government", - "NFT", - "Public Service" - ], - "tags": [ - "Public good", - "Local Impact", - "service", - "public", - "Autonomous World", - "Local Impact", - "Public good" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "atsushi-hayashiatsu" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731574200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E" + "slot_start": 1731402000000, + "slot_end": 1731405600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg" }, "vector": [ 0, @@ -708866,6 +709435,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -709469,7 +710041,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -709707,8 +710278,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -709842,7 +710411,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -710034,7 +710602,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -710063,11 +710630,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -710162,6 +710724,16 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -710175,55 +710747,37 @@ 0, 0, 0, - 0, - 2, 0 ] }, { "session": { - "id": "tales-from-interop", - "sourceId": "UQPDPQ", - "title": "Tales from interop", - "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "synto-nikka", + "sourceId": "ZBSJDY", + "title": "Synto Nikka", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Core Protocol", - "Security", - "Testing", - "devops", - "Core Protocol", - "Security", - "Testing" - ], - "keywords": [ - "DevOps" - ], - "duration": 1433, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "NHsi-lyOEUA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673326163a168eb53561c36a.vtt", - "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0", - "resources_slides": null, - "speakers": [ - "parithosh-jayanthi" - ] + "slot_start": 1731492000000, + "slot_end": 1731497400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -710834,7 +711388,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -710962,7 +711515,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -710981,7 +711533,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -711204,7 +711755,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -711456,7 +712006,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -711524,9 +712073,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -711546,37 +712096,40 @@ }, { "session": { - "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem", - "sourceId": "U7SNLQ", - "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem", - "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": true, + "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance", + "sourceId": "QKMVPC", + "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance", + "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Local/SEA", + "featured": false, "doNotRecord": false, "keywords": [ - "Ethereum", - "Core", - "Development;", - "Social", - "Layer;", - "Governance;", - "Values" + "Population Decline", + "Local Government", + "NFT", + "Public Service" ], "tags": [ - "value" + "Public good", + "Local Impact", + "service", + "public", + "Autonomous World", + "Local Impact", + "Public good" ], "language": "en", "speakers": [ - "ann-brody" + "atsushi-hayashiatsu" ], "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4" + "slot_start": 1731573600000, + "slot_end": 1731574200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E" }, "vector": [ 0, @@ -711584,10 +712137,8 @@ 0, 0, 0, - 6, - 0, - 0, 0, + 6, 0, 0, 0, @@ -712429,6 +712980,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -712563,6 +713116,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -712691,8 +713245,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -712755,6 +713307,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -712783,6 +713336,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -712879,13 +713433,12 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -712896,59 +713449,59 @@ 0, 0, 0, + 2, 0 ] }, { "session": { - "id": "the-10-most-common-vulnerabilities-found-in-audit-contests", - "sourceId": "LYFXZN", - "title": "The 10 Most Common Vulnerabilities Found in Audit Contests", - "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed", - "track": "Security", - "type": "Lightning Talk", + "id": "tales-from-interop", + "sourceId": "UQPDPQ", + "title": "Tales from interop", + "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "tags": [ + "Core Protocol", "Security", - "Auditing", - "audit", - "contest", - "Auditing", - "Security" + "Testing", + "devops", + "Core Protocol", + "Security", + "Testing" ], "keywords": [ - "Vulnerabilities;", - "Audit", - "Contests" + "DevOps" ], - "duration": 595, + "duration": 1433, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "MT7mYhwgksI", + "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d", + "sources_youtubeId": "NHsi-lyOEUA", "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/673326163a168eb53561c36a.vtt", + "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?", "eventId": "devcon-7", - "slot_start": 1731408000000, - "slot_end": 1731408600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII", + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0", "resources_slides": null, "speakers": [ - "jack-sanford" + "parithosh-jayanthi" ] }, "vector": [ - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -713554,9 +714107,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -713682,8 +714235,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -713702,6 +714255,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -713834,7 +714388,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -713926,6 +714479,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -713957,7 +714511,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -714244,8 +714797,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -714261,45 +714814,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-age-of-account-abstraction-opportunities-and-challenges", - "sourceId": "EPN9S7", - "title": "The Age of Account Abstraction: Opportunities and Challenges", - "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.", - "track": "Usability", - "type": "Lightning Talk", + "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem", + "sourceId": "U7SNLQ", + "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem", + "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.", + "track": "Cypherpunk & Privacy", + "type": "Talk", "expertise": "Intermediate", - "audience": "Business", - "featured": false, + "audience": "Developer", + "featured": true, "doNotRecord": false, "keywords": [ - "Protocol competition", - "User growth", - "Layer specialisation" + "Ethereum", + "Core", + "Development;", + "Social", + "Layer;", + "Governance;", + "Values" ], "tags": [ - "Layer 2s", - "Account Abstraction", - "Intents", - "specialisation", - "layer", - "Account Abstraction", - "Intents", - "Layer 2s" + "value" ], "language": "en", "speakers": [ - "daniel-yanev" + "ann-brody" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731552900000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU" + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4" }, "vector": [ 0, @@ -714307,10 +714858,11 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -714912,10 +715464,12 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -715091,11 +715645,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -715106,7 +715658,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -715399,7 +715950,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -715416,6 +715966,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -715536,12 +716094,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -715608,7 +716160,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -715619,46 +716170,56 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-age-of-aggregation", - "sourceId": "VVTWM7", - "title": "The Age Of AGGREGATION", - "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience", - "track": "Layer 2", - "type": "Talk", + "id": "the-10-most-common-vulnerabilities-found-in-audit-contests", + "sourceId": "LYFXZN", + "title": "The 10 Most Common Vulnerabilities Found in Audit Contests", + "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed", + "track": "Security", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Blockchain optimization", - "performance enhancement", - "scalability" - ], "tags": [ - "Protocol Design", - "Scalability", - "Token bridging", - "User Experience", - "Protocol Design", - "Token bridging", - "User Experience" + "Security", + "Auditing", + "audit", + "contest", + "Auditing", + "Security" ], - "language": "en", - "speakers": [ - "sandeep-nailwal" + "keywords": [ + "Vulnerabilities;", + "Audit", + "Contests" ], + "duration": 595, + "language": "en", + "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0", + "sources_youtubeId": "MT7mYhwgksI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731646800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA" + "slot_start": 1731408000000, + "slot_end": 1731408600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII", + "resources_slides": null, + "speakers": [ + "jack-sanford" + ] }, "vector": [ + 6, 0, 0, 0, @@ -715666,7 +716227,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -716271,9 +716831,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -716398,6 +716958,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -716413,7 +716975,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -716443,7 +717004,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -716537,7 +717097,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -716551,6 +717110,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -716600,7 +717160,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -716675,6 +717234,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -716893,6 +717453,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -716964,10 +717525,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -716981,49 +717542,40 @@ }, { "session": { - "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities", - "sourceId": "GSZKVK", - "title": "The Blind Man's Elephant: a product vision towards private identities", - "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.", - "track": "Applied Cryptography", + "id": "the-age-of-account-abstraction-opportunities-and-challenges", + "sourceId": "EPN9S7", + "title": "The Age of Account Abstraction: Opportunities and Challenges", + "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.", + "track": "Usability", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Business", "featured": false, "doNotRecord": false, - "tags": [ - "Privacy", - "Identity", - "ZKP", - "Use Cases", - "selective", - "disclosure", - "Identity", - "Privacy", - "Use Cases", - "ZKP" - ], "keywords": [ - "Selective-disclosure" + "Protocol competition", + "User growth", + "Layer specialisation" + ], + "tags": [ + "Layer 2s", + "Account Abstraction", + "Intents", + "specialisation", + "layer", + "Account Abstraction", + "Intents", + "Layer 2s" ], - "duration": 706, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "-BESF3MUM20", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "daniel-yanev" + ], "eventId": "devcon-7", - "slot_start": 1731395400000, - "slot_end": 1731396000000, + "slot_start": 1731552300000, + "slot_end": 1731552900000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA", - "resources_slides": null, - "speakers": [ - "andy" - ] + "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU" }, "vector": [ 0, @@ -717034,8 +717586,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -717813,13 +718363,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, + 2, 0, 0, 0, @@ -717830,6 +718383,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -717839,11 +718393,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -717881,7 +718433,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -718125,6 +718676,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -718262,7 +718814,8 @@ 0, 0, 2, - 2, + 0, + 0, 0, 0, 0, @@ -718330,10 +718883,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -718348,45 +718901,40 @@ }, { "session": { - "id": "the-chain-abstraction-master-plan", - "sourceId": "DCSCA7", - "title": "The Chain Abstraction Master Plan", - "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.", - "track": "Usability", + "id": "the-age-of-aggregation", + "sourceId": "VVTWM7", + "title": "The Age Of AGGREGATION", + "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience", + "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Chain Abstraction", - "OneBalance", - "Resource Locks" + "Blockchain optimization", + "performance enhancement", + "scalability" ], "tags": [ - "Account Abstraction", - "Cross-L2", - "Developer Infrastructure", - "DevEx", - "Ethereum Roadmap", - "Gas", - "Intents", - "MEV", - "Paymaster", - "Rollups", + "Protocol Design", + "Scalability", + "Token bridging", + "User Experience", + "Protocol Design", "Token bridging", - "Transaction fees mechanisms", "User Experience" ], "language": "en", "speakers": [ - "stephane-gosselin" + "sandeep-nailwal", + "marc-boiron" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731577800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0" + "slot_start": 1731645000000, + "slot_end": 1731646800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA" }, "vector": [ 0, @@ -718396,7 +718944,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -719004,7 +719551,7 @@ 0, 0, 0, - 0, + 6, 6, 0, 0, @@ -719129,7 +719676,9 @@ 0, 0, 0, - 6, + 0, + 0, + 0, 0, 0, 0, @@ -719157,7 +719706,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719167,7 +719715,12 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 2, 0, @@ -719178,11 +719731,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -719266,6 +719816,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -719327,7 +719879,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -719355,7 +719906,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719364,7 +719914,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719558,42 +720107,42 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -719711,35 +720260,49 @@ }, { "session": { - "id": "the-chain-mail-gaze", - "sourceId": "73SKE9", - "title": "The Chain Mail Gaze", - "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.", - "track": "Coordination", + "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities", + "sourceId": "GSZKVK", + "title": "The Blind Man's Elephant: a product vision towards private identities", + "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.", + "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "decolonial" - ], "tags": [ - "Governance", - "Network State", - "decolonial", - "Governance", - "Network State" + "Privacy", + "Identity", + "ZKP", + "Use Cases", + "selective", + "disclosure", + "Identity", + "Privacy", + "Use Cases", + "ZKP" ], - "language": "en", - "speakers": [ - "wassim-z-alsindi" + "keywords": [ + "Selective-disclosure" ], + "duration": 706, + "language": "en", + "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9", + "sources_youtubeId": "-BESF3MUM20", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731409800000, - "slot_end": 1731410400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk" + "slot_start": 1731395400000, + "slot_end": 1731396000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA", + "resources_slides": null, + "speakers": [ + "andy" + ] }, "vector": [ 0, @@ -719752,7 +720315,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -720527,13 +721089,11 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -720559,9 +721119,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -720576,7 +721138,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -720600,6 +721161,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -720980,7 +721542,7 @@ 0, 0, 2, - 0, + 2, 0, 0, 0, @@ -721047,6 +721609,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -721059,36 +721622,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists", - "sourceId": "TPLHFG", - "title": "The challenges of leaving laboratory outbreaks to scientists", - "description": "NA", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Academic", + "id": "the-chain-abstraction-master-plan", + "sourceId": "DCSCA7", + "title": "The Chain Abstraction Master Plan", + "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Chain Abstraction", + "OneBalance", + "Resource Locks" + ], + "tags": [ + "Account Abstraction", + "Cross-L2", + "Developer Infrastructure", + "DevEx", + "Ethereum Roadmap", + "Gas", + "Intents", + "MEV", + "Paymaster", + "Rollups", + "Token bridging", + "Transaction fees mechanisms", + "User Experience" + ], "language": "en", "speakers": [ - "alina-chan" + "stephane-gosselin" ], "eventId": "devcon-7", - "slot_start": 1731567900000, - "slot_end": 1731568500000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ" + "slot_start": 1731576600000, + "slot_end": 1731577800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0" }, "vector": [ - 0, - 6, 0, 0, 0, @@ -721097,6 +721677,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -721829,6 +722410,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -721842,6 +722424,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -721855,6 +722438,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -721864,7 +722448,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -721873,8 +722459,11 @@ 0, 0, 0, + 2, 0, 0, + 2, + 2, 0, 0, 0, @@ -722013,6 +722602,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -722020,8 +722610,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -722046,6 +722638,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -722246,6 +722839,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -722376,13 +722970,7 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -722399,54 +722987,40 @@ 0, 0, 0, - 0, - 2, - 0, - 0, - 0, 0 ] }, { "session": { - "id": "the-combination-of-zkp-mpc-fhe", - "sourceId": "XPLVT8", - "title": "The combination of ZKP +/- MPC +/- FHE", - "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.", - "track": "Applied Cryptography", + "id": "the-chain-mail-gaze", + "sourceId": "73SKE9", + "title": "The Chain Mail Gaze", + "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "ZKP", - "MPC", - "fhe", - "MPC", - "ZKP" - ], "keywords": [ - "FHE" + "decolonial" + ], + "tags": [ + "Governance", + "Network State", + "decolonial", + "Governance", + "Network State" ], - "duration": 521, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "Tq7CVqDE_P4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt", - "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.", - "eventId": "devcon-7", - "slot_start": 1731390000000, - "slot_end": 1731390600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk", - "resources_slides": null, "speakers": [ - "giacomo" - ] + "wassim-z-alsindi" + ], + "eventId": "devcon-7", + "slot_start": 1731409800000, + "slot_end": 1731410400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk" }, "vector": [ 0, @@ -722459,9 +723033,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -723236,6 +723809,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -723262,23 +723836,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, 0, 0, 0, @@ -723301,6 +723858,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -723550,7 +724108,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -723704,6 +724261,21 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -723751,13 +724323,16 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -723771,27 +724346,27 @@ }, { "session": { - "id": "the-dacc-vision-balancing-progress-and-protection", - "sourceId": "AA8SRQ", - "title": "The d/acc Vision: Balancing Progress and Protection", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists", + "sourceId": "TPLHFG", + "title": "The challenges of leaving laboratory outbreaks to scientists", + "description": "NA", "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [], "tags": [], "language": "en", "speakers": [ - "vitalik-buterin" + "alina-chan" ], "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731553800000, + "slot_start": 1731567900000, + "slot_end": 1731568500000, "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo" + "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ" }, "vector": [ 0, @@ -723988,7 +724563,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -724414,6 +724988,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -725095,7 +725671,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -725108,6 +725683,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725116,36 +725692,44 @@ }, { "session": { - "id": "the-daos-of-the-east", - "sourceId": "BUKGLV", - "title": "The DAOs of the East", - "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.", - "track": "Coordination", - "type": "Talk", + "id": "the-combination-of-zkp-mpc-fhe", + "sourceId": "XPLVT8", + "title": "The combination of ZKP +/- MPC +/- FHE", + "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.", + "track": "Applied Cryptography", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [ - "Asia" - ], "tags": [ - "DAO", - "Collective Intelligence", - "Regulation", - "asia", - "Collective Intelligence", - "DAO" + "ZKP", + "MPC", + "fhe", + "MPC", + "ZKP" ], - "language": "en", - "speakers": [ - "joshua-tan" + "keywords": [ + "FHE" ], + "duration": 521, + "language": "en", + "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18", + "sources_youtubeId": "Tq7CVqDE_P4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt", + "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.", "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y" + "slot_start": 1731390000000, + "slot_end": 1731390600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk", + "resources_slides": null, + "speakers": [ + "giacomo" + ] }, "vector": [ 0, @@ -725158,7 +725742,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -725768,6 +726351,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -725920,7 +726504,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -725963,6 +726546,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725976,6 +726560,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725987,13 +726572,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -726251,6 +726834,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -726342,7 +726928,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -726454,10 +727039,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -726470,48 +727055,37 @@ }, { "session": { - "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral", - "sourceId": "C7ZFH3", - "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral", - "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "the-dacc-vision-balancing-progress-and-protection", + "sourceId": "AA8SRQ", + "title": "The d/acc Vision: Balancing Progress and Protection", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Interactive", - "fraud", - "proofs" - ], - "tags": [ - "Optimistic rollups", - "fraud", - "proof", - "Optimistic", - "rollups" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "gabriel-coutinho-de-paula", - "augusto-teixeira" + "vitalik-buterin" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s" + "slot_start": 1731553200000, + "slot_end": 1731553800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -726698,6 +727272,12 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -727125,8 +727705,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -727310,7 +727888,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -727466,7 +728043,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -727587,7 +728163,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -727742,8 +728317,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -727809,6 +728382,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -727821,44 +728395,42 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-end-of-self-custodial-wallets", - "sourceId": "KDUNLM", - "title": "The end of self-custodial wallets", - "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", + "id": "the-daos-of-the-east", + "sourceId": "BUKGLV", + "title": "The DAOs of the East", + "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", - "audience": "Business", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Self custodial", - "FATF", - "wallet" + "Asia" ], "tags": [ - "Free Speech", - "Censorship Resistance", + "DAO", + "Collective Intelligence", "Regulation", - "fatf", - "Censorship Resistance", - "Free Speech", - "Regulation" + "asia", + "Collective Intelligence", + "DAO" ], "language": "en", "speakers": [ - "mikko-ohtamaa" + "joshua-tan" ], "eventId": "devcon-7", - "slot_start": 1731647400000, - "slot_end": 1731648000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg" + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y" }, "vector": [ 0, @@ -727866,15 +728438,13 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -728626,10 +729196,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -728640,6 +729206,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -728712,41 +729279,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, 2, 0, 0, @@ -729096,11 +729628,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -729163,7 +729690,48 @@ 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, @@ -729175,6 +729743,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -729183,35 +729756,38 @@ }, { "session": { - "id": "the-evolution-of-zk-from-1985-2013", - "sourceId": "FGXMGH", - "title": "The Evolution of ZK from 1985-2013", - "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.", - "track": "Applied Cryptography", + "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral", + "sourceId": "C7ZFH3", + "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral", + "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.", + "track": "Layer 2", "type": "Talk", "expertise": "Expert", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "history" + "Interactive", + "fraud", + "proofs" ], "tags": [ - "Zero-Knowledge", - "Cryptography", - "history", - "Cryptography", - "Zero-Knowledge" + "Optimistic rollups", + "fraud", + "proof", + "Optimistic", + "rollups" ], "language": "en", "speakers": [ - "vanishree-rao" + "gabriel-coutinho-de-paula", + "augusto-teixeira" ], "eventId": "devcon-7", - "slot_start": 1731656400000, - "slot_end": 1731658200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE" + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s" }, "vector": [ 0, @@ -729221,9 +729797,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -729693,8 +730266,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -729841,6 +730412,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -729964,8 +730537,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -730026,6 +730597,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -730183,6 +730755,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -730301,6 +730874,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -730456,6 +731030,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -730517,11 +731092,13 @@ 0, 0, 0, - 2, 0, 0, 2, 0, + 2, + 0, + 0, 0, 0, 0, @@ -730536,44 +731113,47 @@ }, { "session": { - "id": "the-fixed-rate-flywheel", - "sourceId": "WYWLXV", - "title": "The Fixed Rate Flywheel", - "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.", - "track": "Cryptoeconomics", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "the-end-of-self-custodial-wallets", + "sourceId": "KDUNLM", + "title": "The end of self-custodial wallets", + "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", "featured": false, "doNotRecord": false, "keywords": [ - "DeFi", - "Fixed Rates" + "Self custodial", + "FATF", + "wallet" ], "tags": [ - "fixed", - "rate" + "Free Speech", + "Censorship Resistance", + "Regulation", + "fatf", + "Censorship Resistance", + "Free Speech", + "Regulation" ], "language": "en", "speakers": [ - "alex-towle", - "merlin-egalite", - "lucas-manuel", - "violet-vienhage" + "mikko-ohtamaa" ], "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731495000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg" + "slot_start": 1731647400000, + "slot_end": 1731648000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg" }, "vector": [ 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -731193,10 +731773,6 @@ 0, 0, 6, - 6, - 6, - 6, - 0, 0, 0, 0, @@ -731338,6 +731914,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -731417,6 +731994,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -731457,6 +732035,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -731811,7 +732390,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -731868,7 +732446,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -731877,6 +732456,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -731890,33 +732471,35 @@ }, { "session": { - "id": "the-franklin-fallacy-why-we-misjudge-new-technologies", - "sourceId": "W7MVPA", - "title": "The Franklin Fallacy: Why We Misjudge New Technologies", - "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk delves into the psychology of this fallacy.", - "track": "Real World Ethereum", + "id": "the-evolution-of-zk-from-1985-2013", + "sourceId": "FGXMGH", + "title": "The Evolution of ZK from 1985-2013", + "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Beginner", - "audience": "Academic", + "expertise": "Expert", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Technological", - "Acceptance" + "history" ], "tags": [ - "e/acc", - "Marketing" + "Zero-Knowledge", + "Cryptography", + "history", + "Cryptography", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "louis-anslow" + "vanishree-rao" ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ" + "slot_start": 1731656400000, + "slot_end": 1731658200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE" }, "vector": [ 0, @@ -731925,11 +732508,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -732398,6 +732981,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -732547,7 +733131,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -732670,6 +733253,9 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, @@ -732813,7 +733399,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -732946,7 +733531,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -733160,6 +733744,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -733224,6 +733809,7 @@ 2, 0, 0, + 2, 0, 0, 0, @@ -733232,8 +733818,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0 @@ -733241,39 +733825,38 @@ }, { "session": { - "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai", - "sourceId": "EK8T9X", - "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI", - "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "the-fixed-rate-flywheel", + "sourceId": "WYWLXV", + "title": "The Fixed Rate Flywheel", + "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.", + "track": "Cryptoeconomics", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "AI" + "DeFi", + "Fixed Rates" ], "tags": [ - "Censorship Resistance", - "Permissionless", - "Privacy" + "fixed", + "rate" ], "language": "en", "speakers": [ - "teana-baker-taylor" + "alex-towle", + "merlin-egalite", + "lucas-manuel", + "violet-vienhage" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731564600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s" + "slot_start": 1731491400000, + "slot_end": 1731495000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg" }, "vector": [ - 0, - 0, - 0, - 0, 0, 0, 6, @@ -733900,6 +734483,10 @@ 0, 0, 6, + 6, + 6, + 6, + 0, 0, 0, 0, @@ -734125,7 +734712,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -734156,7 +734742,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -734200,7 +734785,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -734516,6 +735100,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -734576,9 +735162,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -734592,44 +735180,41 @@ }, { "session": { - "id": "the-future-of-eof-layer-1-layer-2-and-beyond", - "sourceId": "9EBQ3H", - "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!", - "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.", - "track": "Core Protocol", + "id": "the-franklin-fallacy-why-we-misjudge-new-technologies", + "sourceId": "W7MVPA", + "title": "The Franklin Fallacy: Why We Misjudge New Technologies", + "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk delves into the psychology of this fallacy.", + "track": "Real World Ethereum", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "EOF", - "EVM" + "Technological", + "Acceptance" ], "tags": [ - "Layer 1", - "EVM-equivalent", - "Politics", - "EVM", - "EVM-equivalent", - "Layer 1", - "Politics" + "e/acc", + "Marketing" ], "language": "en", "speakers": [ - "danno-ferrin" + "louis-anslow" ], "eventId": "devcon-7", - "slot_start": 1731563400000, - "slot_end": 1731565200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI" + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ" }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -734962,7 +735547,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -735254,6 +735838,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -735379,7 +735964,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -735520,6 +736104,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -735571,7 +736156,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -735654,6 +736238,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -735688,7 +736273,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -735699,7 +736283,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -735926,7 +736509,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -735941,6 +736523,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0 @@ -735948,35 +736532,33 @@ }, { "session": { - "id": "the-future-of-layer-2-research-development-and-next-gen-technologies", - "sourceId": "PJQQSR", - "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies", - "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", + "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai", + "sourceId": "EK8T9X", + "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI", + "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Arbitrum" + "AI" ], "tags": [ - "Layer 2s", - "Scalability", - "arbitrum", - "Layer 2s", - "Scalability" + "Censorship Resistance", + "Permissionless", + "Privacy" ], "language": "en", "speakers": [ - "ed-felten" + "teana-baker-taylor" ], "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k" + "slot_start": 1731564000000, + "slot_end": 1731564600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s" }, "vector": [ 0, @@ -735985,7 +736567,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -736609,6 +737190,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -736783,7 +737365,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -736836,6 +737417,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -736857,7 +737439,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -736867,6 +737448,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -736909,6 +737492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -737223,7 +737807,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -737279,19 +737862,19 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -737301,41 +737884,48 @@ }, { "session": { - "id": "the-future-of-light-clients", - "sourceId": "UL8U8B", - "title": "The Future of Light Clients", - "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.", - "track": "Layer 2", + "id": "the-future-of-eof-layer-1-layer-2-and-beyond", + "sourceId": "9EBQ3H", + "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!", + "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "EOF", + "EVM" + ], "tags": [ - "Layer 2s", - "Light Clients" + "Layer 1", + "EVM-equivalent", + "Politics", + "EVM", + "EVM-equivalent", + "Layer 1", + "Politics" ], "language": "en", "speakers": [ - "noah-citron" + "danno-ferrin" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8" + "slot_start": 1731563400000, + "slot_end": 1731565200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -737664,6 +738254,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -737958,7 +738549,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -738082,10 +738672,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 2, 0, 0, 0, @@ -738131,7 +738721,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -738277,6 +738866,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -738391,6 +738981,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -738401,6 +738992,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -738627,12 +739219,12 @@ 0, 0, 0, + 2, 0, 0, 0, 2, 0, - 2, 0, 0, 0, @@ -738649,33 +739241,35 @@ }, { "session": { - "id": "the-future-of-web3-grants-learnings-from-studying-30-programs", - "sourceId": "F9YCZY", - "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs", - "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "the-future-of-layer-2-research-development-and-next-gen-technologies", + "sourceId": "PJQQSR", + "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies", + "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "Grant", - "Allocation", - "Capital" + "Arbitrum" ], "tags": [ - "capital" + "Layer 2s", + "Scalability", + "arbitrum", + "Layer 2s", + "Scalability" ], "language": "en", "speakers": [ - "eugene-leventhal" + "ed-felten" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731642000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg" + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k" }, "vector": [ 0, @@ -738685,12 +739279,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -739484,6 +740077,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -739557,7 +740151,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -739979,7 +740573,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -739987,12 +740580,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0 @@ -740000,46 +740595,32 @@ }, { "session": { - "id": "the-grand-vision-of-futarchy", - "sourceId": "3UX8GZ", - "title": "The Grand Vision of Futarchy", - "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "the-future-of-light-clients", + "sourceId": "UL8U8B", + "title": "The Future of Light Clients", + "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [], "tags": [ - "Economics", - "Free Speech", - "Futarchy" + "Layer 2s", + "Light Clients" ], "language": "en", "speakers": [ - "robin-hanson" + "noah-citron" ], "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731563100000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE" + "slot_start": 1731493800000, + "slot_end": 1731495600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -740047,6 +740628,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -740292,7 +740874,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -740672,6 +741253,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -740792,13 +741374,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 2, 0, @@ -740846,6 +741426,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -741328,14 +741924,9 @@ 0, 0, 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 2, + 0, 2, 0, 0, @@ -741344,48 +741935,42 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-history-and-philosophy-of-cypherpunk", - "sourceId": "8JVYCQ", - "title": "The History and Philosophy of Cypherpunk", - "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.", - "track": "Cypherpunk & Privacy", - "type": "Talk", + "id": "the-future-of-web3-grants-learnings-from-studying-30-programs", + "sourceId": "F9YCZY", + "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs", + "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.", + "track": "Coordination", + "type": "Lightning Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "mixnets", - "cypherpunk", - "cryptoanarchist" + "Grant", + "Allocation", + "Capital" ], "tags": [ - "Anonymity", - "Censorship Resistance", - "Digital Sovereignty", - "cypherpunk", - "mixnet", - "cryptoanarchy", - "Anonymity", - "Politics", - "Values" + "capital" ], "language": "en", "speakers": [ - "max-hampshire", - "harry-halpin", - "iness-ben-guirat" + "eugene-leventhal" ], "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo" + "slot_start": 1731641400000, + "slot_end": 1731642000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg" }, "vector": [ 0, @@ -741393,13 +741978,14 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -741752,7 +742338,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -742021,7 +742606,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -742152,7 +742736,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742176,7 +742759,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742238,7 +742820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742274,7 +742855,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742461,7 +743041,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742508,7 +743087,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -742634,7 +743212,13 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -742690,6 +743274,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -742710,49 +743296,40 @@ }, { "session": { - "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets", - "sourceId": "TV3QRD", - "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets", - "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.", - "track": "Real World Ethereum", - "type": "Talk", + "id": "the-grand-vision-of-futarchy", + "sourceId": "3UX8GZ", + "title": "The Grand Vision of Futarchy", + "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "Emerging Markets", - "Africa", - "Latin America" - ], + "keywords": [], "tags": [ - "Use Cases", - "RWA", - "Ethereum for Good", - "latin", - "america", - "Ethereum for Good", - "RWA", - "Use Cases" + "Economics", + "Free Speech", + "Futarchy" ], "language": "en", "speakers": [ - "timothy-asiimwe" + "robin-hanson" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ" + "slot_start": 1731562200000, + "slot_end": 1731563100000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -743011,6 +743588,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -743381,7 +743959,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -743512,11 +744089,17 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, + 0, + 2, + 0, + 0, 0, 0, 0, @@ -743563,7 +744146,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -743610,7 +744192,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -743638,7 +744219,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -743994,8 +744574,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -744054,8 +744632,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -744068,48 +744646,60 @@ }, { "session": { - "id": "the-long-con-pig-butchering-drainers-and-job-scams", - "sourceId": "STMCNZ", - "title": "The Long Con: Pig Butchering, Drainers, and Job Scams", - "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.", - "track": "Security", + "id": "the-history-and-philosophy-of-cypherpunk", + "sourceId": "8JVYCQ", + "title": "The History and Philosophy of Cypherpunk", + "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.", + "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "threat", - "intelligence" - ], "tags": [ - "Security", - "Custody", - "threat", - "intelligence", - "Custody", - "Security" + "Anonymity", + "Censorship Resistance", + "Digital Sovereignty", + "cypherpunk", + "mixnet", + "cryptoanarchy", + "Anonymity", + "Politics", + "Values" ], - "language": "en", - "speakers": [ - "luker" + "keywords": [ + "mixnets", + "cypherpunk", + "cryptoanarchist" ], + "duration": 1555, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "prXQJSp_H8A", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt", + "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big", "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk" + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo", + "resources_slides": null, + "speakers": [ + "harry-halpin", + "iness-ben-guirat", + "max-hampshire" + ] }, "vector": [ - 6, - 0, - 0, - 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -744468,6 +745058,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -744738,6 +745329,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -744839,9 +745431,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -744870,6 +745459,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -744893,6 +745483,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -744954,6 +745545,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -744989,6 +745581,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -745092,8 +745685,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -745177,6 +745768,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -745223,6 +745815,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -745319,7 +745912,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745349,6 +745941,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -745423,42 +746017,49 @@ }, { "session": { - "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging", - "sourceId": "V9BA8B", - "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", - "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets", + "sourceId": "TV3QRD", + "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets", + "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Longevity" + "Emerging Markets", + "Africa", + "Latin America" ], "tags": [ - "DeSci", - "e/acc" + "Use Cases", + "RWA", + "Ethereum for Good", + "latin", + "america", + "Ethereum for Good", + "RWA", + "Use Cases" ], "language": "en", "speakers": [ - "nathan-cheng" + "timothy-asiimwe" ], "eventId": "devcon-7", - "slot_start": 1731557580000, - "slot_end": 1731558000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ" }, "vector": [ - 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -746270,6 +746871,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -746316,6 +746918,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -746323,8 +746926,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -746701,6 +747302,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -746752,8 +747355,6 @@ 0, 0, 0, - 2, - 0, 0, 2, 0, @@ -746761,6 +747362,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -746773,41 +747376,39 @@ }, { "session": { - "id": "the-next-700-evm-languages", - "sourceId": "QE7RWH", - "title": "The Next 700 EVM Languages", - "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.", - "track": "Developer Experience", + "id": "the-long-con-pig-butchering-drainers-and-job-scams", + "sourceId": "STMCNZ", + "title": "The Long Con: Pig Butchering, Drainers, and Job Scams", + "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.", + "track": "Security", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "programming languages", - "formal verification", - "smart contracts" + "threat", + "intelligence" ], "tags": [ - "Languages", - "Formal Verification", - "smart", - "contracts" + "Security", + "Custody", + "threat", + "intelligence", + "Custody", + "Security" ], "language": "en", "speakers": [ - "francisco-giordano" + "luker" ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk" }, "vector": [ - 0, - 0, - 0, 6, 0, 0, @@ -747443,9 +748044,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -747547,6 +748148,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -747640,7 +748242,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -747740,7 +748341,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -748028,6 +748628,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -748105,7 +748709,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -748116,6 +748719,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -748127,49 +748732,36 @@ }, { "session": { - "id": "the-next-era-sequencing-and-its-real-impact-on-app-users", - "sourceId": "9M78AK", - "title": "The Next Era: Sequencing and Its Real Impact on App Users", - "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", + "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging", + "sourceId": "V9BA8B", + "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", + "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Layer 2s", - "User Experience", - "Transaction fees mechanisms", - "sequencer", - "Layer 2s", - "Transaction fees mechanisms", - "User Experience" - ], "keywords": [ - "Sequencing" + "Longevity" + ], + "tags": [ + "DeSci", + "e/acc" ], - "duration": 975, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "-S2rlhSUHZY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc", - "resources_slides": null, "speakers": [ - "tina-haibodi" - ] + "nathan-cheng" + ], + "eventId": "devcon-7", + "slot_start": 1731557580000, + "slot_end": 1731558000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso" }, "vector": [ 0, + 6, 0, 0, 0, @@ -748177,8 +748769,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -748923,7 +749513,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -748947,7 +749536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -748973,7 +749561,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -749020,7 +749607,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -749047,6 +749633,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -749068,6 +749655,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -749469,12 +750057,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 2, @@ -749486,49 +750074,51 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-next-generation-of-decentralized-governance", - "sourceId": "WUSAHA", - "title": "The Next Generation of Decentralized Governance", - "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.", - "track": "Coordination", + "id": "the-next-700-evm-languages", + "sourceId": "QE7RWH", + "title": "The Next 700 EVM Languages", + "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.", + "track": "Developer Experience", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [], "keywords": [ - "see", - "doc" + "programming languages", + "formal verification", + "smart contracts" + ], + "tags": [ + "Languages", + "Formal Verification", + "smart", + "contracts" ], - "duration": 1629, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "VhkP2OIwIFY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt", - "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.", - "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E", - "resources_slides": null, "speakers": [ - "tracheopteryx" - ] + "francisco-giordano" + ], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731582000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -749537,8 +750127,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -750363,6 +750951,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -750464,6 +751053,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -750524,8 +751114,8 @@ 0, 0, 0, - 0, - 0, + 2, + 2, 0, 0, 0, @@ -750830,7 +751420,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -750843,41 +751432,52 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-next-generation-of-governors-will-be-modular", - "sourceId": "DEAUWE", - "title": "The next generation of governors will be modular!", - "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.", - "track": "Coordination", - "type": "Lightning Talk", + "id": "the-next-era-sequencing-and-its-real-impact-on-app-users", + "sourceId": "9M78AK", + "title": "The Next Era: Sequencing and Its Real Impact on App Users", + "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.", + "track": "Usability", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Smart contracts", - "modularity" - ], "tags": [ - "Governance", - "Design", - "modular", - "Design", - "Governance" + "Layer 2s", + "User Experience", + "Transaction fees mechanisms", + "sequencer", + "Layer 2s", + "Transaction fees mechanisms", + "User Experience" ], - "language": "en", - "speakers": [ - "hadrien-croubois" + "keywords": [ + "Sequencing" ], + "duration": 975, + "language": "en", + "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d", + "sources_youtubeId": "-S2rlhSUHZY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731490200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE" + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc", + "resources_slides": null, + "speakers": [ + "tina-haibodi" + ] }, "vector": [ 0, @@ -750888,11 +751488,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -751636,6 +752235,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -751659,6 +752259,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -751684,6 +752285,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -751714,7 +752316,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -751731,6 +752332,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -751761,7 +752364,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -751924,7 +752526,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -752184,11 +752785,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -752202,27 +752803,39 @@ }, { "session": { - "id": "the-open-source-orchestra", - "sourceId": "9PWLBV", - "title": "The Open Source Orchestra", - "description": "Member of the Open Source Orchestra", - "track": "Entertainment", - "type": "Music", - "expertise": "Expert", - "audience": "Engineering", + "id": "the-next-generation-of-decentralized-governance", + "sourceId": "WUSAHA", + "title": "The Next Generation of Decentralized Governance", + "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], "tags": [], - "language": "en", - "speakers": [ - "sophia-spirlock" + "keywords": [ + "see", + "doc" ], + "duration": 1629, + "language": "en", + "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603", + "sources_youtubeId": "VhkP2OIwIFY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt", + "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.", "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731556800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY" + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E", + "resources_slides": null, + "speakers": [ + "tracheopteryx" + ] }, "vector": [ 0, @@ -752234,6 +752847,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -752864,10 +753479,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -753524,13 +754139,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 2, - 2, - 0, 0, 0, 0, @@ -753547,36 +754161,39 @@ }, { "session": { - "id": "the-political-economy-of-dacc", - "sourceId": "AXX3JD", - "title": "The political economy of d/acc", - "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "the-next-generation-of-governors-will-be-modular", + "sourceId": "DEAUWE", + "title": "The next generation of governors will be modular!", + "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.", + "track": "Coordination", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc" + "Smart contracts", + "modularity" ], "tags": [ - "Public", - "good" + "Governance", + "Design", + "modular", + "Design", + "Governance" ], "language": "en", "speakers": [ - "eli-dourado" + "hadrien-croubois" ], "eventId": "devcon-7", - "slot_start": 1731553800000, - "slot_end": 1731555000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk" + "slot_start": 1731489600000, + "slot_end": 1731490200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE" }, "vector": [ 0, - 6, 0, 0, 0, @@ -753587,6 +754204,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -753788,7 +754406,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -754218,6 +754835,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -754410,6 +755028,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -754456,6 +755075,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -754619,6 +755239,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -754825,7 +755446,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -754874,6 +755494,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -754884,8 +755505,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -754897,31 +755516,27 @@ }, { "session": { - "id": "the-rated-list", - "sourceId": "QNYDCR", - "title": "The Rated List", - "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "the-open-source-orchestra", + "sourceId": "9PWLBV", + "title": "The Open Source Orchestra", + "description": "Member of the Open Source Orchestra", + "track": "Entertainment", + "type": "Music", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "DAS", - "Data Availability" - ], + "tags": [], "language": "en", "speakers": [ - "hopinheimer", - "chirag-mahaveer-parmar" + "sophia-spirlock" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731487500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4" + "slot_start": 1731553200000, + "slot_end": 1731556800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY" }, "vector": [ 0, @@ -754933,13 +755548,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -755568,7 +756183,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -755729,7 +756343,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -756017,7 +756630,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -756224,11 +756836,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 0, + 2, 2, 0, 0, @@ -756241,51 +756856,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-ripple-effect-of-devcon-vi", - "sourceId": "E3U3XU", - "title": "The Ripple Effect of Devcon VI", - "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.", - "track": "Real World Ethereum", + "id": "the-political-economy-of-dacc", + "sourceId": "AXX3JD", + "title": "The political economy of d/acc", + "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Education" + "d/acc" ], "tags": [ - "Vision", - "Ethereum for Good", - "Local Impact", - "education", - "Ethereum for Good", - "Local Impact", - "Vision" + "Public", + "good" ], "language": "en", "speakers": [ - "julio-cesar-arango" + "eli-dourado" ], "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731560400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak" + "slot_start": 1731553800000, + "slot_end": 1731555000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -756492,6 +757103,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -756924,7 +757538,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -757108,7 +757721,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -757143,7 +757755,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -757251,7 +757862,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -757261,7 +757871,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -757532,6 +758141,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -757601,42 +758213,40 @@ }, { "session": { - "id": "the-rise-of-ai-in-web3-development-ux", - "sourceId": "LTEX8X", - "title": "The Rise of AI in Web3 Development UX", - "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.", - "track": "Usability", + "id": "the-rated-list", + "sourceId": "QNYDCR", + "title": "The Rated List", + "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.", + "track": "[CLS] EPF Day", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "AI Web3", - "LLM", - "Code Generation" - ], + "keywords": [], "tags": [ - "Tooling", - "User Experience", - "UI/UX", - "coding", - "generation", - "Tooling", - "UI/UX", - "User Experience" + "DAS", + "Data Availability" ], "language": "en", "speakers": [ - "stephane-tetsing" + "hopinheimer", + "chirag-mahaveer-parmar" ], "eventId": "devcon-7", - "slot_start": 1731565200000, - "slot_end": 1731565800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0" + "slot_start": 1731486600000, + "slot_end": 1731487500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -758274,6 +758884,11 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -758283,7 +758898,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -758391,12 +759005,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -758722,6 +759334,23 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -758888,30 +759517,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -758936,10 +759541,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 2, 0, @@ -758953,47 +759558,42 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters", - "sourceId": "SEARYQ", - "title": "The rise of Appchains: from L2s to Rollup Clusters", - "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "the-ripple-effect-of-devcon-vi", + "sourceId": "E3U3XU", + "title": "The Ripple Effect of Devcon VI", + "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Fragmentation", - "UX", - "interoperability", - "Rollup Clusters", - "L2" + "Education" ], "tags": [ - "Ethereum Roadmap", - "Appchains", - "Zero-Knowledge", - "interoperability", - "Appchains", - "Ethereum Roadmap", - "Zero-Knowledge" + "Vision", + "Ethereum for Good", + "Local Impact", + "education", + "Ethereum for Good", + "Local Impact", + "Vision" ], "language": "en", "speakers": [ - "alex-gluchowski" + "julio-cesar-arango" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA" + "slot_start": 1731559800000, + "slot_end": 1731560400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak" }, "vector": [ 0, @@ -759002,7 +759602,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -759746,7 +760345,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -759828,6 +760426,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -759862,6 +760461,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -759980,6 +760580,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -760063,7 +760665,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760126,7 +760727,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760296,7 +760896,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760307,6 +760906,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -760318,41 +760919,40 @@ }, { "session": { - "id": "the-role-of-culture-in-shaping-technology-the-case-against-tech-neo-colonialism", - "sourceId": "LRJTXY", - "title": "The role of culture in shaping technology - the case against tech-neo-colonialism", - "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.", - "track": "Real World Ethereum", + "id": "the-rise-of-ai-in-web3-development-ux", + "sourceId": "LTEX8X", + "title": "The Rise of AI in Web3 Development UX", + "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.", + "track": "Usability", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Philosophy", - "Diversity", - "Democracy" + "AI Web3", + "LLM", + "Code Generation" ], "tags": [ - "Network State", - "Digital Sovereignty", - "Decentralization", - "diversity", - "democracy", - "philosophy", - "Decentralization", - "Digital Sovereignty", - "Network State" + "Tooling", + "User Experience", + "UI/UX", + "coding", + "generation", + "Tooling", + "UI/UX", + "User Experience" ], "language": "en", "speakers": [ - "fatemeh-fannizadeh" + "stephane-tetsing" ], "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731561000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k" + "slot_start": 1731565200000, + "slot_end": 1731565800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0" }, "vector": [ 0, @@ -760361,9 +760961,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -760961,7 +761561,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -761003,6 +761602,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -761110,10 +761710,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -761140,10 +761742,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -761153,6 +761753,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -761195,7 +761796,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -761223,7 +761823,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -761657,9 +762256,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 2, 0, @@ -761672,36 +762271,48 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-shape-of-protocols-to-come", - "sourceId": "TYGBPN", - "title": "The Shape of Protocols to Come", - "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.", - "track": "Coordination", + "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters", + "sourceId": "SEARYQ", + "title": "The rise of Appchains: from L2s to Rollup Clusters", + "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", + "expertise": "Intermediate", "audience": "Engineering", - "featured": true, + "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Fragmentation", + "UX", + "interoperability", + "Rollup Clusters", + "L2" + ], "tags": [ "Ethereum Roadmap", - "Protocol Design", - "Use Cases" + "Appchains", + "Zero-Knowledge", + "interoperability", + "Appchains", + "Ethereum Roadmap", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "tim-beiko" + "alex-gluchowski" ], "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, + "slot_start": 1731493800000, + "slot_end": 1731495600000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw" + "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA" }, "vector": [ 0, @@ -761711,11 +762322,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -761894,7 +762505,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -762353,6 +762963,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -762455,6 +763066,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -762488,7 +763100,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -762521,7 +763132,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -762638,6 +763248,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -762679,7 +763290,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -762773,6 +763383,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -762835,6 +763446,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -763004,9 +763616,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 2, 0, @@ -763026,54 +763638,50 @@ }, { "session": { - "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices", - "sourceId": "D8UTDS", - "title": "The Silicon Hospital and a New Way to Make Medical Devices", - "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "the-role-of-culture-in-shaping-technology-the-case-against-tech-neo-colonialism", + "sourceId": "LRJTXY", + "title": "The role of culture in shaping technology - the case against tech-neo-colonialism", + "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Healthcare", - "", - "Medical" + "Philosophy", + "Diversity", + "Democracy" ], "tags": [ - "DeSci", - "Open Source Software", - "Scalability" + "Network State", + "Digital Sovereignty", + "Decentralization", + "diversity", + "democracy", + "philosophy", + "Decentralization", + "Digital Sovereignty", + "Network State" ], "language": "en", "speakers": [ - "mary-lou-jepsen" + "fatemeh-fannizadeh" ], "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731574500000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ" + "slot_start": 1731560400000, + "slot_end": 1731561000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -763673,6 +764281,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -763705,7 +764314,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -763853,8 +764461,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -763893,7 +764503,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -763907,6 +764516,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -763929,7 +764539,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -764320,6 +764929,14 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -764355,11 +764972,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 2, 0, 0, 0, @@ -764370,6 +764982,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -764379,43 +764998,39 @@ }, { "session": { - "id": "the-state-of-web3-support-today-what-just-happened", - "sourceId": "BZRKUD", - "title": "The State of Web3 Support Today: What Just Happened?", - "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.", - "track": "Usability", - "type": "Lightning Talk", + "id": "the-shape-of-protocols-to-come", + "sourceId": "TYGBPN", + "title": "The Shape of Protocols to Come", + "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", - "audience": "Product", - "featured": false, + "audience": "Engineering", + "featured": true, "doNotRecord": false, "tags": [ - "community", - "Accessibility", - "Tooling", - "User Experience" - ], - "keywords": [ - "User Support", - "Community" + "Ethereum Roadmap", + "Protocol Design", + "Use Cases" ], - "duration": 304, + "keywords": [], + "duration": 1402, "language": "en", "sources_swarmHash": "", - "sources_youtubeId": "sur3bRJQw-U", + "sources_youtubeId": "t_2ZIfF9gMc", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, "transcript_vtt": "No VTT link provided", "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731408600000, - "slot_end": 1731409200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k", + "slot_start": 1731409200000, + "slot_end": 1731411000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw", "resources_slides": null, "speakers": [ - "fungible-taco" + "tim-beiko" ] }, "vector": [ @@ -764427,10 +765042,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -764609,6 +765224,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -765068,7 +765684,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -765173,12 +765788,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -765206,6 +765819,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -765217,7 +765831,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -765239,6 +765852,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -765333,7 +765947,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -765354,6 +765967,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -765723,11 +766339,11 @@ 0, 2, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -765741,41 +766357,39 @@ }, { "session": { - "id": "the-supreme-ruler-of-the-world", - "sourceId": "TLWWCW", - "title": "The Supreme Ruler of the World", - "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.", - "track": "Applied Cryptography", - "type": "Talk", + "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices", + "sourceId": "D8UTDS", + "title": "The Silicon Hospital and a New Way to Make Medical Devices", + "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "sumcalc", - "sumcheck" + "Healthcare", + "", + "Medical" ], "tags": [ - "Scalability", - "Validiums", - "Zero-Knowledge", - "sumcheck", - "Scalability", - "Validiums", - "Zero-Knowledge" + "DeSci", + "Open Source Software", + "Scalability" ], "language": "en", "speakers": [ - "don-beaver" + "mary-lou-jepsen" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o" + "slot_start": 1731573600000, + "slot_end": 1731574500000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ" }, "vector": [ 0, + 6, 0, 0, 0, @@ -765785,8 +766399,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -766525,7 +767137,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -766614,6 +767225,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -766648,6 +767261,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -766966,7 +767580,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -767030,7 +767643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -767077,7 +767689,7 @@ 0, 0, 0, - 2, + 0, 0, 2, 0, @@ -767086,6 +767698,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -767097,50 +767711,55 @@ }, { "session": { - "id": "the-tension-between-mev-and-censorship-resistance-gadgets", - "sourceId": "G3MBF7", - "title": "The tension between MEV and Censorship Resistance Gadgets", - "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "the-state-of-web3-support-today-what-just-happened", + "sourceId": "BZRKUD", + "title": "The State of Web3 Support Today: What Just Happened?", + "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Inclusion Lists", - "Protocol Design" - ], "tags": [ - "Ethereum Roadmap", - "Censorship Resistance", - "Design", - "MEV", - "protocol", - "Censorship Resistance", - "Ethereum Roadmap", - "MEV" + "community", + "Accessibility", + "Tooling", + "User Experience" ], - "language": "en", - "speakers": [ - "julian-ma" + "keywords": [ + "User Support", + "Community" ], + "duration": 304, + "language": "en", + "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4", + "sources_youtubeId": "sur3bRJQw-U", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU" + "slot_start": 1731408600000, + "slot_end": 1731409200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k", + "resources_slides": null, + "speakers": [ + "fungible-taco" + ] }, "vector": [ 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -767734,7 +768353,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -767783,6 +768401,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -767872,7 +768491,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -767888,10 +768506,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -767930,6 +768550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -768013,12 +768634,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -768047,6 +768666,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -768107,7 +768727,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -768261,7 +768880,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -768435,7 +769053,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -768443,6 +769060,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -768454,37 +769074,38 @@ }, { "session": { - "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy", - "sourceId": "JESAHN", - "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy", - "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.", - "track": "Layer 2", + "id": "the-supreme-ruler-of-the-world", + "sourceId": "TLWWCW", + "title": "The Supreme Ruler of the World", + "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Wallets" + "sumcalc", + "sumcheck" ], "tags": [ - "Zk Rollups", - "Cross-L2", - "Account Abstraction", - "wallet", - "Account Abstraction", - "Cross-L2", - "Zk Rollups" + "Scalability", + "Validiums", + "Zero-Knowledge", + "sumcheck", + "Scalability", + "Validiums", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "niran-babalola" + "don-beaver" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q" + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o" }, "vector": [ 0, @@ -768494,10 +769115,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -769238,6 +769859,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -769276,25 +769898,11 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -769379,6 +769987,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -769425,7 +770034,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -769653,7 +770261,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -769693,6 +770300,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -769756,6 +770364,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -769787,10 +770403,16 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -769809,57 +770431,48 @@ }, { "session": { - "id": "the-trustless-trade-supply-chain", - "sourceId": "RQZADG", - "title": "The Trustless Trade Supply Chain", - "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "the-tension-between-mev-and-censorship-resistance-gadgets", + "sourceId": "G3MBF7", + "title": "The tension between MEV and Censorship Resistance Gadgets", + "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Expert", "audience": "Research", "featured": false, "doNotRecord": false, + "keywords": [ + "Inclusion Lists", + "Protocol Design" + ], "tags": [ - "PBS", - "MEV", - "Trading", - "Intents", - "TEE", - "Intents", + "Ethereum Roadmap", + "Censorship Resistance", + "Design", "MEV", - "PBS", - "Trading" - ], - "keywords": [ - "TEE" + "protocol", + "Censorship Resistance", + "Ethereum Roadmap", + "MEV" ], - "duration": 460, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "9EPCog8GiiQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt", - "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", - "eventId": "devcon-7", - "slot_start": 1731410400000, - "slot_end": 1731411000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A", - "resources_slides": null, "speakers": [ - "markus" - ] + "julian-ma" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -770455,6 +771068,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -770505,7 +771120,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -770630,7 +771244,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770646,7 +771259,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770673,7 +771285,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770737,10 +771348,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -770786,6 +771399,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -770923,7 +771537,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770983,6 +771596,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -771153,10 +771767,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 2, 0, @@ -771175,47 +771789,47 @@ }, { "session": { - "id": "the-verge-is-not-going-to-break-your-contracts", - "sourceId": "NJXNE3", - "title": "The verge is (not) going to break your contracts!", - "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.", - "track": "Developer Experience", + "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy", + "sourceId": "JESAHN", + "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy", + "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.", + "track": "Layer 2", "type": "Talk", - "expertise": "Expert", - "audience": "Developper", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "compiler" + "Wallets" ], "tags": [ - "Verkle trees", - "Libraries", - "Best Practices", - "compilers", - "Best Practices", - "Libraries", - "Verkle trees" + "Zk Rollups", + "Cross-L2", + "Account Abstraction", + "wallet", + "Account Abstraction", + "Cross-L2", + "Zk Rollups" ], "language": "en", "speakers": [ - "hadrien-croubois" + "niran-babalola" ], "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE" + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -771849,7 +772463,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -771861,6 +772474,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -771957,7 +772572,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -771977,7 +772591,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -771999,6 +772612,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -772016,6 +772630,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -772148,6 +772763,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -772175,7 +772791,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -772265,7 +772880,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -772375,6 +772989,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -772508,6 +773123,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -772520,7 +773136,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -772530,40 +773145,48 @@ }, { "session": { - "id": "the-verifiability-vision", - "sourceId": "KXRMGY", - "title": "The verifiability vision", - "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle", - "track": "Applied Cryptography", - "type": "Talk", + "id": "the-trustless-trade-supply-chain", + "sourceId": "RQZADG", + "title": "The Trustless Trade Supply Chain", + "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.", + "track": "Real World Ethereum", + "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Verifiability", - "proof carrying data", - "succinct proofs" - ], "tags": [ - "Scalability", - "Vision", - "ZKP", - "proof", - "succinct", - "Scalability", - "Vision", - "ZKP" + "PBS", + "MEV", + "Trading", + "Intents", + "TEE", + "Intents", + "MEV", + "PBS", + "Trading" ], - "language": "en", - "speakers": [ - "jens-groth" + "keywords": [ + "TEE" ], + "duration": 460, + "language": "en", + "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a", + "sources_youtubeId": "9EPCog8GiiQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt", + "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731580200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg" + "slot_start": 1731410400000, + "slot_end": 1731411000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A", + "resources_slides": null, + "speakers": [ + "markus" + ] }, "vector": [ 0, @@ -772572,11 +773195,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -773307,6 +773930,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -773342,6 +773967,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -773357,6 +773983,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -773379,11 +774006,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -773444,7 +774071,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -773528,7 +774154,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -773538,7 +774163,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -773636,6 +774260,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -773822,7 +774447,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -773888,43 +774512,42 @@ }, { "session": { - "id": "the-verkle-advantage", - "sourceId": "YLBEZN", - "title": "The verkle advantage", - "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.", - "track": "Core Protocol", + "id": "the-verge-is-not-going-to-break-your-contracts", + "sourceId": "NJXNE3", + "title": "The verge is (not) going to break your contracts!", + "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.", + "track": "Developer Experience", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "stateless" + "compiler" ], "tags": [ - "Core Protocol", - "Protocol Design", "Verkle trees", - "stateless", - "Core Protocol", - "Protocol Design", + "Libraries", + "Best Practices", + "compilers", + "Best Practices", + "Libraries", "Verkle trees" ], "language": "en", "speakers": [ - "guillaume-ballet" + "hadrien-croubois" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4" + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE" }, "vector": [ 0, 0, 0, - 0, 6, 0, 0, @@ -774564,6 +775187,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -774575,8 +775199,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -774673,12 +775295,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -774693,6 +775315,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -774705,7 +775328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -774857,6 +775479,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -774892,6 +775515,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -774978,7 +775605,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775178,7 +775804,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775221,7 +775846,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775234,6 +775858,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -775243,39 +775868,40 @@ }, { "session": { - "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses", - "sourceId": "LCNEGW", - "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses", - "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).", - "track": "Usability", + "id": "the-verifiability-vision", + "sourceId": "KXRMGY", + "title": "The verifiability vision", + "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle", + "track": "Applied Cryptography", "type": "Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Wallets", - "Signers", - "Permissions" + "Verifiability", + "proof carrying data", + "succinct proofs" ], "tags": [ - "Developer Infrastructure", - "User Experience", - "Account Abstraction", - "permissions", - "Account Abstraction", - "Developer Infrastructure", - "User Experience" + "Scalability", + "Vision", + "ZKP", + "proof", + "succinct", + "Scalability", + "Vision", + "ZKP" ], "language": "en", "speakers": [ - "nichanan-kesonpat" + "jens-groth" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, + "slot_start": 1731578400000, + "slot_end": 1731580200000, "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0" + "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg" }, "vector": [ 0, @@ -775286,10 +775912,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -776032,8 +776657,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -776067,10 +776690,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -776097,6 +776718,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776161,6 +776783,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776246,6 +776869,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776255,6 +776879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776578,15 +777203,17 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -776600,62 +777227,43 @@ }, { "session": { - "id": "the-wellbeing-protocol-scaling-localism", - "sourceId": "HC3QGN", - "title": "The Wellbeing Protocol - Scaling Localism", - "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "the-verkle-advantage", + "sourceId": "YLBEZN", + "title": "The verkle advantage", + "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "conviction", - "zealand" + "stateless" ], "tags": [ - "DAO", - "Governance", - "Quadratic Voting", - "Collective Intelligence", - "Conviction", - "Ethereum for Good", - "Public good", - "Climate", - "ReFi", - "Regenerative Applications", - "User Experience", - "zealand", - "Climate", - "Collective Intelligence", - "Conviction", - "DAO", - "Ethereum for Good", - "Governance", - "Public good", - "Quadratic Voting", - "ReFi", - "Regenerative Applications", - "User Experience" + "Core Protocol", + "Protocol Design", + "Verkle trees", + "stateless", + "Core Protocol", + "Protocol Design", + "Verkle trees" ], "language": "en", "speakers": [ - "mark-pascall" + "guillaume-ballet" ], "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731481800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew" + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4" }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -777306,6 +777914,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -777404,12 +778013,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -777422,7 +778031,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -777437,6 +778045,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -777484,12 +778093,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -777497,7 +778104,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -777514,16 +778120,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -777591,13 +778194,20 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -777813,7 +778423,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -777910,7 +778519,7 @@ 0, 0, 2, - 2, + 0, 0, 0, 0, @@ -777956,10 +778565,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -777972,43 +778583,50 @@ }, { "session": { - "id": "things-you-didnt-know-about-contract-deployment", - "sourceId": "GJM9UC", - "title": "Things you didn't know about contract deployment", - "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.", - "track": "Core Protocol", - "type": "Lightning Talk", + "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses", + "sourceId": "LCNEGW", + "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses", + "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).", + "track": "Usability", + "type": "Talk", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Deployment" + "Wallets", + "Signers", + "Permissions" ], "tags": [ - "deployment" + "Developer Infrastructure", + "User Experience", + "Account Abstraction", + "permissions", + "Account Abstraction", + "Developer Infrastructure", + "User Experience" ], "language": "en", "speakers": [ - "theresa-wakonig" + "nichanan-kesonpat" ], "eventId": "devcon-7", "slot_start": 1731470400000, - "slot_end": 1731471000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU" + "slot_end": 1731472200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -778755,6 +779373,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -778789,8 +779408,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -779088,8 +779709,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -779258,6 +779877,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -779305,9 +779925,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -779321,37 +779941,54 @@ }, { "session": { - "id": "this-cursed-machine-post-mortem", - "sourceId": "UBFQ9V", - "title": "THIS CURSED MACHINE Post-Mortem", - "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.", + "id": "the-wellbeing-protocol-scaling-localism", + "sourceId": "HC3QGN", + "title": "The Wellbeing Protocol - Scaling Localism", + "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.", "track": "Real World Ethereum", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Worldbuilding" + "conviction", + "zealand" ], "tags": [ - "Best Practices", - "Gaming", - "Autonomous World", - "worldbuilding", - "Autonomous World", - "Best Practices", - "Gaming" + "DAO", + "Governance", + "Quadratic Voting", + "Collective Intelligence", + "Conviction", + "Ethereum for Good", + "Public good", + "Climate", + "ReFi", + "Regenerative Applications", + "User Experience", + "zealand", + "Climate", + "Collective Intelligence", + "Conviction", + "DAO", + "Ethereum for Good", + "Governance", + "Public good", + "Quadratic Voting", + "ReFi", + "Regenerative Applications", + "User Experience" ], "language": "en", "speakers": [ - "arb" + "mark-pascall" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0" + "slot_start": 1731481200000, + "slot_end": 1731481800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew" }, "vector": [ 0, @@ -780011,7 +780648,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -780110,6 +780746,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -780123,13 +780760,11 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -780191,10 +780826,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -780203,12 +780840,6 @@ 0, 0, 2, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -780225,13 +780856,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -780307,6 +780941,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -780520,6 +781155,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -780616,6 +781252,8 @@ 0, 0, 2, + 2, + 0, 0, 0, 0, @@ -780662,8 +781300,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -780676,36 +781314,37 @@ }, { "session": { - "id": "this-year-in-ethereum", - "sourceId": "MFBX7X", - "title": "This year in Ethereum", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", + "id": "things-you-didnt-know-about-contract-deployment", + "sourceId": "GJM9UC", + "title": "Things you didn't know about contract deployment", + "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Deployment" + ], + "tags": [ + "deployment" + ], "language": "en", "speakers": [ - "josh-stark" + "theresa-wakonig" ], "eventId": "devcon-7", - "slot_start": 1731381300000, - "slot_end": 1731382800000, - "slot_roomId": "main-stage", - "sources_youtubeId": "YyK8i2-0aPk", - "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY" + "slot_start": 1731470400000, + "slot_end": 1731471000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU" }, "vector": [ 0, 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -781359,6 +781998,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -781791,6 +782431,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -782004,10 +782645,11 @@ 2, 0, 0, - 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -782022,45 +782664,43 @@ }, { "session": { - "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum", - "sourceId": "QNSX9R", - "title": "Time is all you need: optimizing Dutch auctions on Arbitrum", - "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring the optimal auction execution times, as well as optimal decay curves, for blockchain based trading. Using simulations and real data, we present our findings on this topic, as well as proposed solutions to achieve the optimal outcomes.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "this-cursed-machine-post-mortem", + "sourceId": "UBFQ9V", + "title": "THIS CURSED MACHINE Post-Mortem", + "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Dutch", - "auctions" + "Worldbuilding" ], "tags": [ - "Decentralization Improvements", - "Layer 2s", - "Mechanism design", - "MEV", - "auction", - "dutch", - "Decentralization Improvements", - "Layer 2s", - "Mechanism design", - "MEV" + "Best Practices", + "Gaming", + "Autonomous World", + "worldbuilding", + "Autonomous World", + "Best Practices", + "Gaming" ], "language": "en", "speakers": [ - "brad-bachu", - "cody-born", - "alan-wu" + "arb" ], "eventId": "devcon-7", - "slot_start": 1731489000000, - "slot_end": 1731489600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU" + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0" }, "vector": [ + 0, + 0, + 0, + 0, 0, 0, 6, @@ -782716,14 +783356,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -782801,12 +783439,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -782832,6 +783467,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -782865,7 +783501,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -782911,6 +783546,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -783127,7 +783764,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -783361,8 +783997,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -783372,6 +784006,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -783383,39 +784020,29 @@ }, { "session": { - "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data", - "sourceId": "RTVKJC", - "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data", - "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "this-year-in-ethereum", + "sourceId": "MFBX7X", + "title": "This year in Ethereum", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "User Sovereignty", - "Infrastructure", - "Oracle" - ], - "tags": [ - "Identity", - "ZKP", - "MPC", - "oracle", - "Identity", - "MPC", - "ZKP" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "sinu" + "josh-stark" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731577200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo" + "slot_start": 1731381300000, + "slot_end": 1731382800000, + "slot_roomId": "main-stage", + "sources_youtubeId": "YyK8i2-0aPk", + "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a", + "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY" }, "vector": [ 0, @@ -783424,11 +784051,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -784078,10 +784705,11 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -784205,7 +784833,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -784231,7 +784858,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -784245,7 +784871,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -784594,7 +785219,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -784718,10 +785342,14 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -784740,40 +785368,45 @@ }, { "session": { - "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient", - "sourceId": "Z8EEGW", - "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient", - "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.", - "track": "Core Protocol", - "type": "Talk", + "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum", + "sourceId": "QNSX9R", + "title": "Time is all you need: optimizing Dutch auctions on Arbitrum", + "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring the optimal auction execution times, as well as optimal decay curves, for blockchain based trading. Using simulations and real data, we present our findings on this topic, as well as proposed solutions to achieve the optimal outcomes.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "statelessness" + "Dutch", + "auctions" ], "tags": [ - "Light Clients", - "Zero-Knowledge", - "statelessness", - "Light Clients", - "Zero-Knowledge" + "Decentralization Improvements", + "Layer 2s", + "Mechanism design", + "MEV", + "auction", + "dutch", + "Decentralization Improvements", + "Layer 2s", + "Mechanism design", + "MEV" ], "language": "en", "speakers": [ - "jason-chaskin", - "gajinder-singh" + "brad-bachu", + "cody-born", + "alan-wu" ], "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731492000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM" + "slot_start": 1731489000000, + "slot_end": 1731489600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU" }, "vector": [ - 0, - 0, 0, 0, 6, @@ -785435,16 +786068,9 @@ 0, 0, 0, - 0, 6, 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 6, 0, 0, 0, @@ -785526,14 +786152,8 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, + 6, + 6, 0, 0, 0, @@ -785592,6 +786212,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -785853,6 +786474,20 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -786072,12 +786707,13 @@ 0, 0, 0, + 0, 2, 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -786094,25 +786730,39 @@ }, { "session": { - "id": "tomo-dj-set", - "sourceId": "3FTAT3", - "title": "Tomo DJ Set", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data", + "sourceId": "RTVKJC", + "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data", + "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "User Sovereignty", + "Infrastructure", + "Oracle" + ], + "tags": [ + "Identity", + "ZKP", + "MPC", + "oracle", + "Identity", + "MPC", + "ZKP" + ], "language": "en", - "speakers": [], + "speakers": [ + "sinu" + ], "eventId": "devcon-7", - "slot_start": 1731583800000, - "slot_end": 1731588600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU" + "slot_start": 1731576600000, + "slot_end": 1731577200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo" }, "vector": [ 0, @@ -786124,13 +786774,8 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, + 6, 0, 0, 0, @@ -786784,6 +787429,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -786907,6 +787553,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -786932,6 +787579,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -786945,6 +787593,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -787293,6 +787942,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -787419,6 +788069,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -787437,47 +788088,44 @@ }, { "session": { - "id": "top-hacks-since-devcon-vi-what-did-we-learn", - "sourceId": "FCWCBG", - "title": "Top Hacks since Devcon VI: what did we learn?", - "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!", - "track": "Security", - "type": "Workshop", + "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient", + "sourceId": "Z8EEGW", + "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient", + "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Learnings", - "War Rooms" + "statelessness" ], "tags": [ - "Security", - "Hacks", - "Use Cases", - "war", - "room", - "Hacks", - "Security", - "Use Cases" + "Light Clients", + "Zero-Knowledge", + "statelessness", + "Light Clients", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "matthias-egli", - "mudit-gupta" + "jason-chaskin", + "gajinder-singh" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731488400000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE" + "slot_start": 1731490200000, + "slot_end": 1731492000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM" }, "vector": [ - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -787725,7 +788373,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -787920,7 +788567,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -788139,6 +788785,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -788211,7 +788859,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -788224,6 +788871,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -788231,6 +788879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -788290,7 +788939,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -788462,7 +789110,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -788738,7 +789385,8 @@ 0, 0, 2, - 2, + 0, + 0, 0, 0, 0, @@ -788795,43 +789443,32 @@ }, { "session": { - "id": "top-opcode-offenders-in-the-zkevm", - "sourceId": "DJL7RP", - "title": "Top opcode offenders in the zkEVM", - "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", + "id": "tomo-dj-set", + "sourceId": "3FTAT3", + "title": "Tomo DJ Set", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "zk-resources", - "GAS costs", - "top offenders" - ], - "tags": [ - "Core Protocol", - "Layer 2s", - "Zk Rollups", - "top", - "offenders", - "Core Protocol", - "Layer 2s", - "Zk Rollups" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "carlos-matallana", - "jesus" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731492000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao" + "slot_start": 1731583800000, + "slot_end": 1731588600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -789337,7 +789974,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -789498,7 +790134,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -789589,7 +790224,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -789636,10 +790270,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -790098,8 +790730,7 @@ 0, 0, 0, - 2, - 2, + 0, 0, 0, 0, @@ -790136,6 +790767,8 @@ 0, 0, 2, + 0, + 0, 2, 0, 0, @@ -790154,47 +790787,42 @@ }, { "session": { - "id": "tracing-integration-in-lighthouse", - "sourceId": "RVZX3C", - "title": "Tracing Integration in Lighthouse", - "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "top-hacks-since-devcon-vi-what-did-we-learn", + "sourceId": "FCWCBG", + "title": "Top Hacks since Devcon VI: what did we learn?", + "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!", + "track": "Security", + "type": "Workshop", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Learnings", + "War Rooms" + ], "tags": [ - "Core Protocol", - "Frameworks" + "Security", + "Hacks", + "Use Cases", + "war", + "room", + "Hacks", + "Security", + "Use Cases" ], "language": "en", "speakers": [ - "sayan" + "matthias-egli", + "mudit-gupta" ], "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731474900000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE" + "slot_start": 1731483000000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -790447,6 +791075,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -790641,6 +791270,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -790847,15 +791477,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -790937,11 +791558,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -791020,10 +791641,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -791193,6 +791814,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -791466,6 +792088,26 @@ 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, @@ -791484,6 +792126,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -791502,55 +792146,48 @@ }, { "session": { - "id": "transaction-simulation-the-good-the-bad-and-the-ugly", - "sourceId": "TE9JUF", - "title": "Transaction simulation, the good, the bad & the ugly", - "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "top-opcode-offenders-in-the-zkevm", + "sourceId": "DJL7RP", + "title": "Top opcode offenders in the zkEVM", + "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Security", - "User Experience", - "safety", - "Security", - "User Experience" - ], "keywords": [ - "simulation", - "wallet", - "safety" + "zk-resources", + "GAS costs", + "top offenders" + ], + "tags": [ + "Core Protocol", + "Layer 2s", + "Zk Rollups", + "top", + "offenders", + "Core Protocol", + "Layer 2s", + "Zk Rollups" ], - "duration": 458, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "6-ygj7_IqEg", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt", - "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you", - "eventId": "devcon-7", - "slot_start": 1731409800000, - "slot_end": 1731410400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4", - "resources_slides": null, "speakers": [ - "kim-persson" - ] + "carlos-matallana", + "jesus" + ], + "eventId": "devcon-7", + "slot_start": 1731490200000, + "slot_end": 1731492000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao" }, "vector": [ - 6, - 0, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -792051,6 +792688,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -792282,7 +792920,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -792298,13 +792935,13 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -792351,8 +792988,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -792582,7 +793221,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -792812,6 +793450,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -792844,11 +793484,11 @@ 0, 0, 0, - 2, 0, 0, 0, 2, + 2, 0, 0, 0, @@ -792866,35 +793506,30 @@ }, { "session": { - "id": "transforming-systems-lessons-from-taiwans-movements", - "sourceId": "B9EDKY", - "title": "Transforming Systems: Lessons from Taiwan's Movements", - "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.", - "track": "Coordination", - "type": "Talk", + "id": "tracing-integration-in-lighthouse", + "sourceId": "RVZX3C", + "title": "Tracing Integration in Lighthouse", + "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Ecosystem", - "Funding", - "Mainstream" - ], + "keywords": [], "tags": [ - "Civil Resistance", - "Coordination", - "Public good" + "Core Protocol", + "Frameworks" ], "language": "en", "speakers": [ - "noah-yeh" + "sayan" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731639900000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk" + "slot_start": 1731474900000, + "slot_end": 1731475800000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE" }, "vector": [ 0, @@ -792908,12 +793543,11 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -793656,6 +794290,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -793740,11 +794376,13 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -793790,7 +794428,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -793865,7 +794502,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -794201,12 +794837,12 @@ 0, 2, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -794219,55 +794855,48 @@ }, { "session": { - "id": "transitioning-from-an-l1-to-an-l2-a-case-study", - "sourceId": "KHVZ9M", - "title": "Transitioning from an L1 to an L2: A case study", - "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.", - "track": "Layer 2", + "id": "transaction-simulation-the-good-the-bad-and-the-ugly", + "sourceId": "TE9JUF", + "title": "Transaction simulation, the good, the bad & the ugly", + "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years", + "track": "Security", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Layer2", - "case study", - "technical learnings" - ], "tags": [ - "Layer 1", - "Layer 2s", - "Rollups", - "Scalability", - "Optimistic rollups", - "Use Cases", - "learnings", - "technical", - "Layer 1", - "Layer 2s", - "Optimistic rollups", - "Rollups", - "Scalability", - "Use Cases" + "Security", + "User Experience", + "safety", + "Security", + "User Experience" ], - "language": "en", - "speakers": [ - "marek-olszewski" + "keywords": [ + "simulation", + "wallet", + "safety" ], + "duration": 458, + "language": "en", + "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f", + "sources_youtubeId": "6-ygj7_IqEg", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt", + "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you", "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg" + "slot_start": 1731409800000, + "slot_end": 1731410400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4", + "resources_slides": null, + "speakers": [ + "kim-persson" + ] }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -794798,14 +795427,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -794945,6 +795566,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -795030,6 +795652,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -795041,44 +795664,12 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -795139,7 +795730,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -795347,6 +795937,55 @@ 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, @@ -795529,8 +796168,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -795583,42 +796220,42 @@ }, { "session": { - "id": "trust-minimized-p2p-marketplaces-on-ethereum", - "sourceId": "YPNBE8", - "title": "Trust-minimized P2P marketplaces on Ethereum", - "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", + "id": "transforming-systems-lessons-from-taiwans-movements", + "sourceId": "B9EDKY", + "title": "Transforming Systems: Lessons from Taiwan's Movements", + "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "TLSNotary", - "ZKEmail", - "P2P marketplaces" + "Ecosystem", + "Funding", + "Mainstream" ], "tags": [ - "ZKP", - "Signatures", - "P2P finance", - "p2p", - "marketplace", - "P2P finance", - "Signatures", - "ZKP" + "Civil Resistance", + "Coordination", + "Public good" ], "language": "en", "speakers": [ - "richard" + "noah-yeh" ], "eventId": "devcon-7", - "slot_start": 1731556200000, - "slot_end": 1731556800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8" + "slot_start": 1731638700000, + "slot_end": 1731639900000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -795752,7 +796389,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -796285,6 +796921,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -796432,7 +797069,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -796449,7 +797085,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -796464,6 +797099,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -796509,6 +797145,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -796585,6 +797222,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -796655,7 +797293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -796889,8 +797526,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -796926,7 +797561,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -796935,41 +797569,51 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created", - "sourceId": "R9ENCP", - "title": "Trust Zones: Why DAOs will be the best organizations ever created", - "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.", - "track": "Coordination", + "id": "transitioning-from-an-l1-to-an-l2-a-case-study", + "sourceId": "KHVZ9M", + "title": "Transitioning from an L1 to an L2: A case study", + "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.", + "track": "Layer 2", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Trust" + "Layer2", + "case study", + "technical learnings" ], "tags": [ - "DAO", - "Governance", - "trusted", - "DAO", - "Governance" + "Layer 1", + "Layer 2s", + "Rollups", + "Scalability", + "Optimistic rollups", + "Use Cases", + "learnings", + "technical", + "Layer 1", + "Layer 2s", + "Optimistic rollups", + "Rollups", + "Scalability", + "Use Cases" ], "language": "en", "speakers": [ - "spencer-graham" + "marek-olszewski" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU" + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg" }, "vector": [ 0, @@ -796979,10 +797623,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 6, 0, 0, @@ -797513,6 +798153,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -797642,7 +798283,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -797730,6 +798370,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -797756,6 +798397,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -797779,7 +798421,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -797790,6 +798434,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -797806,12 +798451,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -797852,6 +798495,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -797882,7 +798526,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -798242,6 +798885,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -798294,50 +798939,49 @@ }, { "session": { - "id": "try-it-out-in-remix", - "sourceId": "SUEJQR", - "title": "Try it out in Remix", - "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", + "id": "trust-minimized-p2p-marketplaces-on-ethereum", + "sourceId": "YPNBE8", + "title": "Trust-minimized P2P marketplaces on Ethereum", + "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "AI" + "TLSNotary", + "ZKEmail", + "P2P marketplaces" ], "tags": [ - "Layer 2s", - "Tooling", - "DevRel", - "Desktop", - "ai", - "Desktop", - "DevRel", - "Layer 2s", - "Tooling" + "ZKP", + "Signatures", + "P2P finance", + "p2p", + "marketplace", + "P2P finance", + "Signatures", + "ZKP" ], "language": "en", "speakers": [ - "rob-stupay" + "richard" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw" + "slot_start": 1731556200000, + "slot_end": 1731556800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8" }, "vector": [ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -798464,6 +799108,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -799000,7 +799645,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -799088,7 +799732,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -799133,7 +799776,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -799164,6 +799806,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -799241,34 +799884,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, @@ -799398,6 +800013,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -799601,7 +800217,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -799632,6 +800247,32 @@ 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, @@ -799643,6 +800284,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -799651,41 +800298,40 @@ }, { "session": { - "id": "txain-discover-the-next-generation-of-blockchain-exploration", - "sourceId": "WRGHRM", - "title": "TXain: Discover the Next Generation of Blockchain Exploration", - "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch", - "track": "Developer Experience", + "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created", + "sourceId": "R9ENCP", + "title": "Trust Zones: Why DAOs will be the best organizations ever created", + "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.", + "track": "Coordination", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Developer", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "blockchain explorer", - "user experience", - "Real-Time Data" + "Trust" ], "tags": [ - "data", - "real-time" + "DAO", + "Governance", + "trusted", + "DAO", + "Governance" ], "language": "en", "speakers": [ - "joan-baylina", - "daniel" + "spencer-graham" ], "eventId": "devcon-7", - "slot_start": 1731493200000, - "slot_end": 1731493800000, + "slot_start": 1731488400000, + "slot_end": 1731489000000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg" + "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -799694,6 +800340,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -799852,7 +800499,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -800518,10 +801164,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -800592,6 +801240,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -800730,8 +801379,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -800955,7 +801602,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -800999,39 +801645,52 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "txmonster-mud-day-demo", - "sourceId": "3GSMUH", - "title": "TxMonster - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "try-it-out-in-remix", + "sourceId": "SUEJQR", + "title": "Try it out in Remix", + "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "N/A" + "AI" + ], + "tags": [ + "Layer 2s", + "Tooling", + "DevRel", + "Desktop", + "ai", + "Desktop", + "DevRel", + "Layer 2s", + "Tooling" ], - "tags": [], "language": "en", "speakers": [ - "buidltxgames" + "rob-stupay" ], "eventId": "devcon-7", - "slot_start": 1731558000000, - "slot_end": 1731558300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -801041,8 +801700,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -801790,6 +802447,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -801834,6 +802492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -801847,6 +802506,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -801940,6 +802600,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -802299,7 +802960,7 @@ 0, 0, 0, - 0, + 2, 0, 0, 0, @@ -802344,44 +803005,46 @@ 0, 0, 0, - 0, - 0, 0 ] }, { "session": { - "id": "ultimate-dominion-mud-day-demo", - "sourceId": "GPQVMW", - "title": "Ultimate Dominion - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "txain-discover-the-next-generation-of-blockchain-exploration", + "sourceId": "WRGHRM", + "title": "TXain: Discover the Next Generation of Blockchain Exploration", + "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch", + "track": "Developer Experience", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "blockchain explorer", + "user experience", + "Real-Time Data" + ], "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" + "data", + "real-time" ], "language": "en", "speakers": [ - "ritz-raspa" + "joan-baylina", + "daniel" ], "eventId": "devcon-7", - "slot_start": 1731558300000, - "slot_end": 1731558600000, + "slot_start": 1731493200000, + "slot_end": 1731493800000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU" + "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -802391,7 +803054,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -802549,6 +803211,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -803051,9 +803714,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, @@ -803227,8 +803890,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -803430,6 +804091,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -803653,6 +804315,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -803685,9 +804348,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -803701,37 +804364,29 @@ }, { "session": { - "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api", - "sourceId": "VBUJML", - "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API", - "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.", - "track": "Coordination", + "id": "txmonster-mud-day-demo", + "sourceId": "3GSMUH", + "title": "TxMonster - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "none" - ], - "tags": [ - "Coordination", - "Decentralization", - "Ethereum for Good", - "Coordination", - "Decentralization", - "Ethereum for Good" + "N/A" ], + "tags": [], "language": "en", "speakers": [ - "thomas-jay-rush", - "meriam-zandi" + "buidltxgames" ], "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731492600000, + "slot_start": 1731558000000, + "slot_end": 1731558300000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0" + "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM" }, "vector": [ 0, @@ -803745,6 +804400,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -804407,10 +805063,56 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -804574,7 +805276,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -804598,51 +805299,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, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -805038,12 +805694,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -805056,50 +805712,38 @@ }, { "session": { - "id": "understanding-eip-7002-and-eip-6110", - "sourceId": "KPD8HB", - "title": "Understanding EIP-7002 and EIP-6110", - "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "ultimate-dominion-mud-day-demo", + "sourceId": "GPQVMW", + "title": "Ultimate Dominion - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, + "keywords": [], "tags": [ - "Staking" - ], - "keywords": [ - "EIP", - "validator", - "staking" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], - "duration": 1495, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "EyDChjFQEkQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt", - "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.", - "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731398400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0", - "resources_slides": null, "speakers": [ - "lucas-saldanha", - "stefan-bratanov" - ] + "ritz-raspa" + ], + "eventId": "devcon-7", + "slot_start": 1731558300000, + "slot_end": 1731558600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -805108,6 +805752,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -805770,10 +806415,9 @@ 0, 0, 0, + 6, 0, 0, - 6, - 6, 0, 0, 0, @@ -805945,6 +806589,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -805962,7 +806608,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -806395,7 +807040,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -806405,6 +807049,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -806417,44 +807063,37 @@ }, { "session": { - "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both", - "sourceId": "HZCDFP", - "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?", - "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?", - "track": "Layer 2", - "type": "Panel", + "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api", + "sourceId": "VBUJML", + "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API", + "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.", + "track": "Coordination", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "ERC-7683", - "Interoperability", - "Unified-Ethereum" + "none" ], "tags": [ - "Cross-L2", - "UI/UX", - "Intents", - "ethereum", - "unified", - "Cross-L2", - "Intents", - "UI/UX" + "Coordination", + "Decentralization", + "Ethereum for Good", + "Coordination", + "Decentralization", + "Ethereum for Good" ], "language": "en", "speakers": [ - "hart-lambur", - "ben-jones", - "vitalik-buterin", - "steven-goldfeder", - "jesse-pollak" + "thomas-jay-rush", + "meriam-zandi" ], "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731483000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y" + "slot_start": 1731492000000, + "slot_end": 1731492600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0" }, "vector": [ 0, @@ -806464,11 +807103,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -806651,7 +807290,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -806893,7 +807531,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -806956,7 +807593,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -807250,11 +807886,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -807303,6 +807937,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -807325,6 +807961,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -807353,6 +807990,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -807395,7 +808038,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -807502,7 +808144,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -807731,7 +808372,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -807765,8 +808405,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -807779,34 +808419,43 @@ }, { "session": { - "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure", - "sourceId": "NX7U8B", - "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure", - "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.", + "id": "understanding-eip-7002-and-eip-6110", + "sourceId": "KPD8HB", + "title": "Understanding EIP-7002 and EIP-6110", + "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.", "track": "Core Protocol", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ENS" - ], "tags": [ - "ens", - "Accessibility", - "Public good", - "Use cases of cryptography" + "Staking" ], - "language": "en", - "speakers": [ - "estmcmxcieth" + "keywords": [ + "EIP", + "validator", + "staking" ], + "duration": 1495, + "language": "en", + "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34", + "sources_youtubeId": "EyDChjFQEkQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt", + "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.", "eventId": "devcon-7", - "slot_start": 1731467100000, - "slot_end": 1731467700000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo" + "slot_start": 1731396600000, + "slot_end": 1731398400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0", + "resources_slides": null, + "speakers": [ + "lucas-saldanha", + "stefan-bratanov" + ] }, "vector": [ 0, @@ -808487,9 +809136,7 @@ 0, 0, 0, - 0, - 0, - 0, + 6, 6, 0, 0, @@ -808575,39 +809222,11 @@ 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, - 2, 0, 0, 0, @@ -808656,7 +809275,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -808708,6 +809326,35 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -809084,7 +809731,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -809109,7 +809755,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -809118,6 +809763,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -809131,39 +809781,44 @@ }, { "session": { - "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop", - "sourceId": "VPMQGM", - "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop", - "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.", - "track": "Applied Cryptography", - "type": "Workshop", + "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both", + "sourceId": "HZCDFP", + "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?", + "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?", + "track": "Layer 2", + "type": "Panel", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "oracle" + "ERC-7683", + "Interoperability", + "Unified-Ethereum" ], "tags": [ - "Live Coding", - "Privacy", - "MPC", - "oracle", - "Live Coding", - "MPC", - "Privacy" + "Cross-L2", + "UI/UX", + "Intents", + "ethereum", + "unified", + "Cross-L2", + "Intents", + "UI/UX" ], "language": "en", "speakers": [ - "hendrik-eeckhaut", - "sinu", - "tsukino" + "hart-lambur", + "ben-jones", + "vitalik-buterin", + "steven-goldfeder", + "jesse-pollak" ], "eventId": "devcon-7", - "slot_start": 1731577200000, - "slot_end": 1731582600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0" + "slot_start": 1731479400000, + "slot_end": 1731483000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y" }, "vector": [ 0, @@ -809173,9 +809828,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -809363,6 +810015,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -809604,6 +810257,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -809666,6 +810320,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -809829,8 +810484,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -809962,9 +810615,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -809993,7 +810648,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -810020,8 +810674,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -810110,6 +810762,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -810215,6 +810868,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -810342,7 +810996,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -810443,6 +811096,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -810472,9 +811128,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -810488,38 +811144,36 @@ }, { "session": { - "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2", - "sourceId": "NGZBJL", - "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2", - "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.", - "track": "Layer 2", - "type": "Talk", + "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure", + "sourceId": "NX7U8B", + "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure", + "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.", + "track": "Core Protocol", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Developper", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Privacy", - "Scalability", - "Statelessness" + "ENS" ], "tags": [ - "statelessness" + "ens", + "Accessibility", + "Public good", + "Use cases of cryptography" ], "language": "en", "speakers": [ - "leona-hioki" + "estmcmxcieth" ], "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ" + "slot_start": 1731467100000, + "slot_end": 1731467700000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo" }, "vector": [ - 0, - 0, - 0, 0, 0, 0, @@ -811201,6 +811855,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -811286,6 +811941,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811317,6 +811973,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811365,6 +812022,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811780,7 +812438,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811793,6 +812450,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811822,6 +812480,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811829,7 +812488,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811839,39 +812497,39 @@ }, { "session": { - "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities", - "sourceId": "N3JJFU", - "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities", - "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop", + "sourceId": "VPMQGM", + "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop", + "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.", + "track": "Applied Cryptography", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "DeFi" + "oracle" ], "tags": [ - "Regulation", - "UI/UX", - "Account Abstraction", - "Economics", - "defi", - "Account Abstraction", - "Economics", - "Regulation", - "UI/UX" + "Live Coding", + "Privacy", + "MPC", + "oracle", + "Live Coding", + "MPC", + "Privacy" ], "language": "en", "speakers": [ - "charles-st-louis" + "hendrik-eeckhaut", + "sinu", + "tsukino" ], "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY" + "slot_start": 1731577200000, + "slot_end": 1731582600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0" }, "vector": [ 0, @@ -811880,14 +812538,11 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -812541,6 +813196,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -812560,6 +813216,8 @@ 0, 0, 6, + 6, + 0, 0, 0, 0, @@ -812647,7 +813305,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812663,7 +813320,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812671,7 +813327,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812705,6 +813360,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -812719,7 +813375,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812732,6 +813387,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -812805,7 +813462,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -813053,6 +813709,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -813191,56 +813848,50 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling", - "sourceId": "87XNSS", - "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling", - "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?", - "track": "Core Protocol", - "type": "Lightning Talk", + "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2", + "sourceId": "NGZBJL", + "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2", + "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.", + "track": "Layer 2", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "EOF", - "EIP-7692", - "EVM" + "Privacy", + "Scalability", + "Statelessness" ], "tags": [ - "Core Protocol", - "Developer Infrastructure", - "DevEx", - "EVM", - "Core Protocol", - "Developer Infrastructure", - "DevEx" + "statelessness" ], "language": "en", "speakers": [ - "nebojsa-urosevic", - "pavle-drobnjak" + "leona-hioki" ], "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731562800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8" + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ" }, "vector": [ 0, 0, 0, 0, - 6, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -813919,7 +814570,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -813989,7 +814639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -814000,7 +814649,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -814024,7 +814672,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -814177,7 +814824,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -814502,6 +815148,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -814532,7 +815182,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -814548,56 +815197,58 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0 ] }, { "session": { - "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks", - "sourceId": "TZVK7F", - "title": "Updating Gas Cost Schedule based on reproducible benchmarks", - "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.", - "track": "Core Protocol", + "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities", + "sourceId": "N3JJFU", + "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities", + "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.", + "track": "Real World Ethereum", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Gas Cost Schedule", - "EVM Internals", - "Client Diversity", - "Node Infrastructure" + "DeFi" ], "tags": [ - "Gas", - "Decentralization", - "infrastructure", - "node", - "Decentralization", - "Gas" + "Regulation", + "UI/UX", + "Account Abstraction", + "Economics", + "defi", + "Account Abstraction", + "Economics", + "Regulation", + "UI/UX" ], "language": "en", "speakers": [ - "jacek-glen" + "charles-st-louis" ], "eventId": "devcon-7", - "slot_start": 1731572400000, - "slot_end": 1731573000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs" + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY" }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -815365,6 +816016,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -815379,6 +816032,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -815386,6 +816040,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -815399,7 +816054,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -815429,12 +816083,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -815515,12 +816169,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -815555,7 +816209,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -815889,10 +816542,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -815906,53 +816559,58 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "usc-ultimate-solidity-championship", - "sourceId": "UE8WVS", - "title": "USC Ultimate Solidity Championship", - "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", + "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling", + "sourceId": "87XNSS", + "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling", + "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Solidity", - "Programming", - "Competition" + "EOF", + "EIP-7692", + "EVM" ], "tags": [ - "Art", - "Hacks", - "Public good" + "Core Protocol", + "Developer Infrastructure", + "DevEx", + "EVM", + "Core Protocol", + "Developer Infrastructure", + "DevEx" ], "language": "en", "speakers": [ - "five" + "nebojsa-urosevic", + "pavle-drobnjak" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU" + "slot_start": 1731562200000, + "slot_end": 1731562800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -816630,6 +817288,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -816699,6 +817359,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816709,6 +817370,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816732,6 +817394,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816788,8 +817451,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -816888,6 +817549,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816931,7 +817593,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -817241,13 +817902,12 @@ 0, 0, 0, + 2, 0, 0, 0, 2, 0, - 2, - 0, 0, 0, 0, @@ -817264,39 +817924,39 @@ }, { "session": { - "id": "using-reth-execution-extensions-for-next-generation-indexing", - "sourceId": "YUFRTQ", - "title": "Using Reth Execution Extensions for next generation indexing", - "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?", + "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks", + "sourceId": "TZVK7F", + "title": "Updating Gas Cost Schedule based on reproducible benchmarks", + "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.", "track": "Core Protocol", - "type": "Talk", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "client", - "plugin", - "indexer" + "Gas Cost Schedule", + "EVM Internals", + "Client Diversity", + "Node Infrastructure" ], "tags": [ - "Layer 1", - "Developer Infrastructure", - "Tooling", - "plugin", - "Developer Infrastructure", - "Layer 1", - "Tooling" + "Gas", + "Decentralization", + "infrastructure", + "node", + "Decentralization", + "Gas" ], "language": "en", "speakers": [ - "alexey-shekhirin" + "jacek-glen" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, + "slot_start": 1731572400000, + "slot_end": 1731573000000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE" + "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs" }, "vector": [ 0, @@ -818052,13 +818712,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -818091,7 +818749,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -818113,6 +818770,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -818142,6 +818800,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -818227,6 +818886,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -818268,6 +818928,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -818575,7 +819237,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -818603,12 +819264,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -818621,41 +819282,35 @@ }, { "session": { - "id": "utilizing-national-ids-in-the-ethereum-ecosystem", - "sourceId": "PR78EL", - "title": "Utilizing national IDs in the Ethereum ecosystem", - "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Intermediate", + "id": "usc-ultimate-solidity-championship", + "sourceId": "UE8WVS", + "title": "USC Ultimate Solidity Championship", + "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "National IDs", - "Selective Disclosure" + "Solidity", + "Programming", + "Competition" ], "tags": [ - "Civil Resistance", - "Privacy", - "Identity", - "Civil Resistance", - "Identity", - "Privacy" + "Art", + "Hacks", + "Public good" ], "language": "en", "speakers": [ - "yanis", - "michael-elliot", - "hiroyuki-tachibana", - "florent", - "nico" + "five" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731555900000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU" }, "vector": [ 0, @@ -818664,12 +819319,10 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -818767,7 +819420,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -818832,8 +819484,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -819348,8 +819998,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -819445,7 +820093,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -819514,6 +820161,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -819626,30 +820274,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, @@ -819680,6 +820304,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -819958,10 +820598,26 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -819980,48 +820636,52 @@ }, { "session": { - "id": "vadcops-leveraging-starks-for-tailored-proof-generation", - "sourceId": "BEJPG8", - "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation", - "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.", - "track": "Applied Cryptography", + "id": "using-reth-execution-extensions-for-next-generation-indexing", + "sourceId": "YUFRTQ", + "title": "Using Reth Execution Extensions for next generation indexing", + "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?", + "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "STARKs", - "VADCOPs", - "" + "client", + "plugin", + "indexer" ], "tags": [ - "vadcops" + "Layer 1", + "Developer Infrastructure", + "Tooling", + "plugin", + "Developer Infrastructure", + "Layer 1", + "Tooling" ], "language": "en", "speakers": [ - "hector-masip-ardevol", - "felicia-barcelo" + "alexey-shekhirin" ], "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0" + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -820701,8 +821361,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -820767,11 +821425,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -820804,6 +821464,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -821310,6 +821971,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -821332,47 +821994,50 @@ }, { "session": { - "id": "verifier-alliance-inside-of-the-contract-verification-pipeline", - "sourceId": "Q3EDF8", - "title": "Verifier Alliance: inside of the contract verification pipeline", - "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).", - "track": "Developer Experience", - "type": "Lightning Talk", + "id": "utilizing-national-ids-in-the-ethereum-ecosystem", + "sourceId": "PR78EL", + "title": "Utilizing national IDs in the Ethereum ecosystem", + "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.", + "track": "Real World Ethereum", + "type": "Panel", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Contract", - "Verification" + "National IDs", + "Selective Disclosure" ], "tags": [ - "DevEx", - "verification", - "contracts", - "DevEx" + "Civil Resistance", + "Privacy", + "Identity", + "Civil Resistance", + "Identity", + "Privacy" ], "language": "en", "speakers": [ - "rim-rakhimov" + "yanis", + "michael-elliot", + "hiroyuki-tachibana", + "florent", + "nico" ], "eventId": "devcon-7", - "slot_start": 1731472800000, - "slot_end": 1731473400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ" + "slot_start": 1731552300000, + "slot_end": 1731555900000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g" }, "vector": [ - 0, - 0, - 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -821475,6 +822140,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -821539,6 +822205,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -822054,10 +822722,11 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -822131,7 +822800,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -822151,6 +822819,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -822218,6 +822887,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -822332,6 +823002,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -822361,7 +823032,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -822523,7 +823193,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -822667,9 +823336,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -822685,35 +823354,34 @@ }, { "session": { - "id": "verkle-integration-in-reth", - "sourceId": "T8LKTM", - "title": "Verkle integration in reth", - "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", + "id": "vadcops-leveraging-starks-for-tailored-proof-generation", + "sourceId": "BEJPG8", + "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation", + "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Stateless clients", - "Verge" + "STARKs", + "VADCOPs", + "" ], "tags": [ - "EPF", - "Core Protocol", - "Cryptography", - "Verkle trees" + "vadcops" ], "language": "en", "speakers": [ - "aditya-gupta" + "hector-masip-ardevol", + "felicia-barcelo" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731473100000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI" + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0" }, "vector": [ 0, @@ -822726,12 +823394,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -823409,9 +824077,10 @@ 0, 0, 0, + 6, + 6, 0, 0, - 6, 0, 0, 0, @@ -823467,13 +824136,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -823757,7 +824424,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -823773,7 +824439,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -823997,6 +824662,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -824016,9 +824683,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 2, @@ -824033,39 +824701,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "viruses-and-chronic-aging-building-a-research-community", - "sourceId": "FX8UQF", - "title": "Viruses and Chronic Aging: Building a Research Community", - "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "verifier-alliance-inside-of-the-contract-verification-pipeline", + "sourceId": "Q3EDF8", + "title": "Verifier Alliance: inside of the contract verification pipeline", + "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).", + "track": "Developer Experience", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Community", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Contract", + "Verification" + ], + "tags": [ + "DevEx", + "verification", + "contracts", + "DevEx" + ], "language": "en", "speakers": [ - "amy-proal" + "rim-rakhimov" ], "eventId": "devcon-7", - "slot_start": 1731572700000, - "slot_end": 1731573600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY" + "slot_start": 1731472800000, + "slot_end": 1731473400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ" }, "vector": [ - 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -824831,6 +825507,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -825061,6 +825738,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -825221,6 +825899,36 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -825331,51 +826039,21 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0 @@ -825383,32 +826061,37 @@ }, { "session": { - "id": "visions-of-a-viable-dacc-biosafety-strategy", - "sourceId": "7VDGQM", - "title": "Visions of a Viable d/acc Biosafety Strategy", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "verkle-integration-in-reth", + "sourceId": "T8LKTM", + "title": "Verkle integration in reth", + "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.", + "track": "[CLS] EPF Day", "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Stateless clients", + "Verge" + ], + "tags": [ + "EPF", + "Core Protocol", + "Cryptography", + "Verkle trees" + ], "language": "en", "speakers": [ - "vitalik-buterin" + "aditya-gupta" ], "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731567900000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko" + "slot_start": 1731472200000, + "slot_end": 1731473100000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI" }, "vector": [ - 0, - 6, - 0, 0, 0, 0, @@ -825424,6 +826107,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -825600,7 +826284,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -826105,6 +826788,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -826160,11 +826844,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -826340,6 +827026,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -826448,6 +827135,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -826705,9 +827393,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 2, @@ -826722,53 +827410,40 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption", - "sourceId": "ZAYEXK", - "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption", - "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.", - "track": "Cypherpunk & Privacy", + "id": "viruses-and-chronic-aging-building-a-research-community", + "sourceId": "FX8UQF", + "title": "Viruses and Chronic Aging: Building a Research Community", + "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "Beginner", + "expertise": "Intermediate", "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "culture", - "aesthetics", - "communication" - ], - "tags": [ - "Coordination", - "Identity", - "Design", - "communication", - "Coordination", - "Design", - "Identity" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "ira-nezhynska" + "amy-proal" ], "eventId": "devcon-7", - "slot_start": 1731495000000, - "slot_end": 1731495600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q" + "slot_start": 1731572700000, + "slot_end": 1731573600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY" }, "vector": [ 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -827550,7 +828225,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -827644,7 +828318,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -827656,7 +828329,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -827762,7 +828434,9 @@ 0, 0, 0, - 2, + 0, + 0, + 0, 0, 0, 0, @@ -828072,6 +828746,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -828085,44 +828761,34 @@ }, { "session": { - "id": "vlsmsanalyzing-faulty-distributed-systems", - "sourceId": "AKRLKH", - "title": "VLSMs—analyzing faulty distributed systems", - "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "visions-of-a-viable-dacc-biosafety-strategy", + "sourceId": "7VDGQM", + "title": "Visions of a Viable d/acc Biosafety Strategy", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Correct-by-construction" - ], - "tags": [ - "Consensus", - "Distributed validator technology", - "Formal Verification", - "correct-by-construction", - "Consensus", - "Distributed validator technology", - "Formal Verification" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "vlad-zamfir" + "vitalik-buterin" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8" + "slot_start": 1731567600000, + "slot_end": 1731567900000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko" }, "vector": [ 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -828312,6 +828978,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -828816,7 +829486,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -828861,7 +829530,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -829053,7 +829721,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -829323,7 +829990,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -829396,7 +830062,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -829423,6 +830088,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -829435,43 +830101,45 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "voices-of-tech-and-open-source-movement-across-asia", - "sourceId": "QCPSDK", - "title": "Voices of Tech & Open Source Movement Across Asia", - "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.", + "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption", + "sourceId": "ZAYEXK", + "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption", + "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.", "track": "Cypherpunk & Privacy", - "type": "Panel", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "FOSS", - "Regional", - "Insights" + "culture", + "aesthetics", + "communication" ], "tags": [ - "FOSS", - "regional", - "insights" + "Coordination", + "Identity", + "Design", + "communication", + "Coordination", + "Design", + "Identity" ], "language": "en", "speakers": [ - "hong-phuc-dang", - "mario-behling", - "brianna-chang", - "mishari-muqbil" + "ira-nezhynska" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731472200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU" + "slot_start": 1731495000000, + "slot_end": 1731495600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q" }, "vector": [ 0, @@ -830172,10 +830840,6 @@ 0, 0, 0, - 0, - 6, - 6, - 6, 6, 0, 0, @@ -830266,6 +830930,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -830359,6 +831024,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -830370,6 +831036,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -830476,6 +831143,23 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -830546,7 +831230,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -830753,20 +831436,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -830778,12 +831447,12 @@ 0, 2, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -830796,43 +831465,44 @@ }, { "session": { - "id": "voting-with-time-commitment", - "sourceId": "7V7QNK", - "title": "Voting with time commitment", - "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.", - "track": "Cryptoeconomics", + "id": "vlsmsanalyzing-faulty-distributed-systems", + "sourceId": "AKRLKH", + "title": "VLSMs—analyzing faulty distributed systems", + "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant", + "track": "Core Protocol", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Voting" + "Correct-by-construction" ], "tags": [ - "Governance", - "Mechanism design", - "voting", - "Governance", - "Mechanism design" + "Consensus", + "Distributed validator technology", + "Formal Verification", + "correct-by-construction", + "Consensus", + "Distributed validator technology", + "Formal Verification" ], "language": "en", "speakers": [ - "vijay-mohan" + "vlad-zamfir" ], "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731491400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM" + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8" }, "vector": [ 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -831527,10 +832197,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -831661,7 +832331,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -831767,6 +832436,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -831926,7 +832596,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -832035,6 +832704,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -832107,6 +832777,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -832127,12 +832799,12 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, 0, 0, 0, @@ -832149,40 +832821,38 @@ }, { "session": { - "id": "wallet-infra-101-and-where-innovation-needs-to-happen", - "sourceId": "RQAAFS", - "title": "Wallet Infra 101, & where innovation needs to happen", - "description": "In this talk I hope to go over the infrastructure stack of a standard wallet, and then also go into where in this stack I think innovation should happen/is already happening and why that's exciting. This will also broadly cover other related topics such as: \r\n- The future state of crypto UI & dapp interactions\r\n- What crypto wallets can learn from web2 apps \r\n- My framework around \"What users can do with their balance?\", and how wallets can use that to build new features", - "track": "Usability", - "type": "Lightning Talk", + "id": "voices-of-tech-and-open-source-movement-across-asia", + "sourceId": "QCPSDK", + "title": "Voices of Tech & Open Source Movement Across Asia", + "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.", + "track": "Cypherpunk & Privacy", + "type": "Panel", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "wallet", - "dapps", - "" + "FOSS", + "Regional", + "Insights" ], "tags": [ - "Accessibility", - "Account Abstraction", - "Architecture", - "Frameworks", - "Gas", - "Intents", - "Payment", - "UI/UX" + "FOSS", + "regional", + "insights" ], "language": "en", "speakers": [ - "medha-kothari" + "hong-phuc-dang", + "mario-behling", + "brianna-chang", + "mishari-muqbil" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731559200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k" + "slot_start": 1731468600000, + "slot_end": 1731472200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU" }, "vector": [ 0, @@ -832190,10 +832860,13 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -832882,6 +833555,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -832889,7 +833566,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -832974,18 +833650,13 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, - 2, - 2, 0, - 2, 0, 0, 0, @@ -833028,7 +833699,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -833064,7 +833734,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -833151,7 +833820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -833260,6 +833928,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -833466,6 +834135,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -833507,55 +834178,46 @@ }, { "session": { - "id": "wallet-ux-panel", - "sourceId": "9HACGK", - "title": "Wallet UX Panel", - "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.", - "track": "Usability", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "id": "voting-with-time-commitment", + "sourceId": "7V7QNK", + "title": "Voting with time commitment", + "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Wallets", - "User Experience", - "Standards" + "Voting" ], "tags": [ - "Coordination", - "Custody", - "Account Abstraction", - "standards", - "Account Abstraction", - "Coordination", - "Custody" + "Governance", + "Mechanism design", + "voting", + "Governance", + "Mechanism design" ], "language": "en", "speakers": [ - "lukas-schor", - "derek-rein", - "arik-galansky", - "adam-ceresko", - "chintan-turakhia" + "vijay-mohan" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731475800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew" + "slot_start": 1731489600000, + "slot_end": 1731491400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -834252,10 +834914,6 @@ 0, 0, 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -834297,6 +834955,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -834335,7 +834994,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -834386,6 +835044,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834429,7 +835088,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -834439,7 +835097,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -834652,6 +835309,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834764,7 +835422,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -834848,12 +835505,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 2, 0, @@ -834863,30 +835522,50 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "warren-winter", - "sourceId": "9PWLDW", - "title": "Warren Winter", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "wallet-infra-101-and-where-innovation-needs-to-happen", + "sourceId": "RQAAFS", + "title": "Wallet Infra 101, & where innovation needs to happen", + "description": "In this talk I hope to go over the infrastructure stack of a standard wallet, and then also go into where in this stack I think innovation should happen/is already happening and why that's exciting. This will also broadly cover other related topics such as: \r\n- The future state of crypto UI & dapp interactions\r\n- What crypto wallets can learn from web2 apps \r\n- My framework around \"What users can do with their balance?\", and how wallets can use that to build new features", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "wallet", + "dapps", + "" + ], + "tags": [ + "Accessibility", + "Account Abstraction", + "Architecture", + "Frameworks", + "Gas", + "Intents", + "Payment", + "UI/UX" + ], "language": "en", - "speakers": [], + "speakers": [ + "medha-kothari" + ], "eventId": "devcon-7", - "slot_start": 1731577500000, - "slot_end": 1731580200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ" + "slot_start": 1731558600000, + "slot_end": 1731559200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k" }, "vector": [ 0, @@ -834897,7 +835576,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -835595,6 +836273,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -835679,13 +836358,18 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, + 2, + 2, 0, + 2, 0, 0, 0, @@ -835728,6 +836412,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -835763,6 +836448,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -835851,6 +836537,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -836182,16 +836870,8 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, + 0, + 2, 0, 2, 0, @@ -836211,25 +836891,43 @@ }, { "session": { - "id": "web3-poetry-day-1", - "sourceId": "VDMFMR", - "title": "Web3 Poetry - Day 1", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "wallet-ux-panel", + "sourceId": "9HACGK", + "title": "Wallet UX Panel", + "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.", + "track": "Usability", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Wallets", + "User Experience", + "Standards" + ], + "tags": [ + "Coordination", + "Custody", + "Account Abstraction", + "standards", + "Account Abstraction", + "Coordination", + "Custody" + ], "language": "en", - "speakers": [], + "speakers": [ + "lukas-schor", + "derek-rein", + "arik-galansky", + "adam-ceresko", + "chintan-turakhia" + ], "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731402000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA" + "slot_start": 1731472200000, + "slot_end": 1731475800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew" }, "vector": [ 0, @@ -836240,7 +836938,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -836939,6 +837636,11 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -837018,6 +837720,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -837111,6 +837814,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -837120,6 +837824,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -837444,12 +838149,7 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -837536,12 +838236,11 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -837554,9 +838253,9 @@ }, { "session": { - "id": "web3-poetry-day-3", - "sourceId": "GN8LTB", - "title": "Web3 Poetry - Day 3", + "id": "warren-winter", + "sourceId": "9PWLDW", + "title": "Warren Winter", "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", "track": "Entertainment", "type": "Music", @@ -837569,10 +838268,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731574800000, + "slot_start": 1731577500000, + "slot_end": 1731580200000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY" + "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ" }, "vector": [ 0, @@ -838876,6 +839575,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -838897,9 +839597,9 @@ }, { "session": { - "id": "web3-poetry-jam", - "sourceId": "V79DXK", - "title": "Web3 Poetry Jam", + "id": "web3-poetry-day-1", + "sourceId": "VDMFMR", + "title": "Web3 Poetry - Day 1", "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", "track": "Entertainment", "type": "Music", @@ -838912,10 +839612,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, + "slot_start": 1731398400000, + "slot_end": 1731402000000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY" + "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA" }, "vector": [ 0, @@ -840219,6 +840919,7 @@ 0, 0, 0, + 0, 2, 0, 0, @@ -840240,37 +840941,27 @@ }, { "session": { - "id": "web3-security-is-embarrasing", - "sourceId": "VNFNDM", - "title": "Web3 Security is Embarrasing", - "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", + "id": "web3-poetry-day-3", + "sourceId": "GN8LTB", + "title": "Web3 Poetry - Day 3", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "phishing", - "protection" - ], - "tags": [ - "Security", - "Sustainability", - "User Experience" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "andrew-macpherson" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731573000000, + "slot_start": 1731571200000, "slot_end": 1731574800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM" + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY" }, "vector": [ - 6, 0, 0, 0, @@ -840280,6 +840971,12 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -840980,7 +841677,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -841008,7 +841704,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -841024,7 +841719,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -841358,7 +842052,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -841570,8 +842263,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 2, @@ -841592,42 +842285,25 @@ }, { "session": { - "id": "web3-user-research-101", - "sourceId": "7YZGVW", - "title": "Web3 User Research 101", - "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.", - "track": "Usability", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Design", - "featured": true, + "id": "web3-poetry-jam", + "sourceId": "V79DXK", + "title": "Web3 Poetry Jam", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, "doNotRecord": false, - "keywords": [ - "101" - ], - "tags": [ - "Best Practices", - "User Experience", - "UI/UX", - "User Research", - "Design Thinking", - "101", - "Best Practices", - "Design Thinking", - "UI/UX", - "User Experience", - "User Research" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "mindy-harrell", - "kristina-mayman" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731405600000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y" + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY" }, "vector": [ 0, @@ -841638,6 +842314,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -842341,8 +843018,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -842384,7 +843059,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -842399,7 +843073,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -842427,7 +843100,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -842455,7 +843127,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -842512,7 +843183,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -842911,7 +843581,13 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -842935,6 +843611,8 @@ 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -842945,55 +843623,49 @@ 0, 0, 0, - 2, 0, 0 ] }, { "session": { - "id": "wen-p2p-electronic-cash-system", - "sourceId": "ZFX3ZF", - "title": "Wen p2p Electronic Cash System?", - "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).", - "track": "Real World Ethereum", + "id": "web3-security-is-embarrasing", + "sourceId": "VNFNDM", + "title": "Web3 Security is Embarrasing", + "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!", + "track": "Security", "type": "Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "payments", - "cash", - "stablecoins" + "phishing", + "protection" ], "tags": [ - "Conviction", - "Payment", - "Account Abstraction", - "stablecoin", - "Account Abstraction", - "Conviction", - "Payment" + "Security", + "Sustainability", + "User Experience" ], "language": "en", "speakers": [ - "konrad-urban" + "andrew-macpherson" ], "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY" + "slot_start": 1731573000000, + "slot_end": 1731574800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -843152,7 +843824,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -843699,6 +844370,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -843726,6 +844398,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -843741,6 +844414,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -843776,7 +844450,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -843866,7 +844539,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -844076,6 +844748,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -844150,7 +844825,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -844180,7 +844854,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -844291,11 +844964,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -844309,37 +844982,42 @@ }, { "session": { - "id": "western-liberalism-to-world-liberalism", - "sourceId": "H8N9CP", - "title": "Western liberalism to world liberalism", - "description": "Western liberalism to world liberalism", - "track": "Real World Ethereum", - "type": "Panel", + "id": "web3-user-research-101", + "sourceId": "7YZGVW", + "title": "Web3 User Research 101", + "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.", + "track": "Usability", + "type": "Workshop", "expertise": "Beginner", - "audience": "Community", - "featured": false, + "audience": "Design", + "featured": true, "doNotRecord": false, "keywords": [ - "liberalism" + "101" ], "tags": [ - "Ethereum for Good", - "Free Speech", - "Network State" + "Best Practices", + "User Experience", + "UI/UX", + "User Research", + "Design Thinking", + "101", + "Best Practices", + "Design Thinking", + "UI/UX", + "User Experience", + "User Research" ], "language": "en", "speakers": [ - "diego-fernandez", - "bruno-macaes", - "vitalik-buterin", - "afra-zhao-wang", - "ahmed-gatnash" + "mindy-harrell", + "kristina-mayman" ], "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731657600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw" + "slot_start": 1731398400000, + "slot_end": 1731405600000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y" }, "vector": [ 0, @@ -844348,9 +845026,10 @@ 0, 0, 0, - 6, 0, 0, + 6, + 0, 0, 0, 0, @@ -844536,7 +845215,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844779,7 +845457,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844861,7 +845538,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844876,7 +845552,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844920,7 +845595,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -845058,6 +845732,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -845099,6 +845775,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -845107,13 +845784,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -845127,7 +845804,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -845142,6 +845818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -845169,6 +845846,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -845206,7 +845884,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -845226,6 +845903,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -845624,6 +846302,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -845651,44 +846330,61 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0 ] }, { "session": { - "id": "what-defi-founders-can-learn-from-web2", - "sourceId": "QB8CGR", - "title": "What DeFi Founders Can Learn From Web2", - "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.", + "id": "wen-p2p-electronic-cash-system", + "sourceId": "ZFX3ZF", + "title": "Wen p2p Electronic Cash System?", + "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).", "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Business", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, + "tags": [ + "Conviction", + "Payment", + "Account Abstraction", + "stablecoin", + "Account Abstraction", + "Conviction", + "Payment" + ], "keywords": [ - "Metrics", - "Unit economics", - "Growth" + "payments", + "cash", + "stablecoins" ], - "tags": [], + "duration": 1549, "language": "en", - "speakers": [ - "mike-silagadze" - ], + "sources_swarmHash": "", + "sources_youtubeId": "7JFFfcT1yzI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673321cc3a168eb53554b6fe.vtt", + "transcript_text": " Hello. Hello. Cool. Who knows in which year the peer-to-peer electronic cash system paper came out? Anyone else? I'm sure you know. Just three people? Four people? Okay, which year was it? 2008, right? So we're still waiting for that peer-to-peer electronic cash. I think it's fair to say that we've not taken over the peer-to-peer payments world. Bitcoin has definitely found PMF product market fit with store of value. And I don't want to argue that there are no payments on Bitcoin. But clearly, the last payments you've made to come here, maybe with your Grab or Bolt or Uber were probably not Bitcoin or on-chain payments at all. Just to show how ancient this paper is, this is 2008, right? So in 2008, GTA 4 came out. That's how long ago this was. The iPhone just came out a year earlier. People dressed like this. I think it's cool, but also very, very ancient. Bitcoin was largely, well, came out right in time as a perfect reaction to the financial crisis of 2007-2008. This is how long ago it was. a perfect reaction to the financial crisis of 2007-8. This is how long ago it was. I think we all here know what peer-to-peer means, but let's briefly talk about the cash part, because I think it's very easy to think of cash as payments. But payments are not exactly cash. I would say that cash payments are a subset of all payments. And usually when we talk about payments, we talk about something that's much, much more complicated. So last time you ordered your Grab to get here, you made probably a credit card payment. With that there was a very big bundle of services that enabled things like chargebacks, maybe you were using a credit card and definitely there are some points and rewards so I'm still waiting for the visa and MasterCard airdrop. But I would just want to talk about the simplest of payments like this very raw payment which just goes payer to payee without all of these bundled services. So this is what we usually mean by cash payment, right? Like if I give 100 baht to a taxi driver, there's no way to charge back unless I hunt him down somehow. There are also no points and there's definitely not a credit system. So for today, I'd briefly like to talk about why we haven't taken over the world yet and what's needed to take over the world with on-chain payments. So I'll give a mini intro about myself and then we'll go through a mini history just to honor our ancestors. And then I'll talk through five narratives that were popular, or that are popular, to answer, like, this is the blocker. Like, we can't have payments because of, I don't know, scalability, let's say, right? So these will be the five Topics that we'll analyze So about me. I'm the peanut brain at peanut protocol. You can look me up Here and also DM me here So, let's go and honor our ancestors I think I think it's really important to realize the first wave of blockchains and categorize these very briefly. So we had Bitcoin, which I already mentioned, and then we had a bunch of payments projects that were strictly about this cash element, strictly about making payments happen. So I think Litecoin fits that category very well, and Dash definitely does. Stellar, I would say, too. Then we have private payments, Monero and Zcash. The only ones with smart contracts are Nex and Ethereum, by the way. So despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. Despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. So when I was prepping for this talk, I had the honor to talk to some of these ancestors and people who are working on these very ancient projects. And I asked them, like, how are you going about trying to bootstrap your payment network? And one of the guys I talked to, he was running a campaign in 2017 trying to convince parking garages and, like, very local shops in one local city in the US to adopt their coin as one of the payment methods. As you might guess, it's quite a hopeless endeavor endeavor because you not only have to convince the garages, but also you have to convince all the drivers to adopt your thing in an ecosystem where there is the dollar already and people are used to coins and dollar notes. So what's the advantage of bootstrapping that one token, one chain thing? I think quite similarly, we have... Who's been at ECC this year? Nice. Cool. You might have seen the payments cafe by base. They were selling cappuccinos where you could just take your Coinbase wallet and just make a payment for a cappuccino. And there I wondered, well, isn't it the same case? What's my reason to switch over from that? Like opening up my wallet and so on when I'm so used to just tapping my card, right? Especially that was just USDC on base with which you could pay. So here are the candidates. One common narrative will be scalability. So we need fast and cheap for transactions I'll kind of argue against that then another one is privacy I think highly important in a world where we have full adoption and most payments happen On chain, but I will also argue that we can have a world where settlement happens on chain butts And stuff is still reasonably private. Then another argument that is very common is, well, payments are not on chain yet, or haven't captured a whole payments market in TratFi because stablecoins are relatively new. I'll also argue against that. And then finally, for the 4337 mafia, one common argument is, hey, we need better account management. We have to have account abstraction, all these nice UX improvements. I will also say, well, that's not the main blocker here. And then finally, we'll go into the interrupt thesis. So let's start. I think this is a very common thing, especially in the early days of blockchains. This was a very, very common thing to hear when people were pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. we're pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. So Visa has 24,000 TPS, and my blockchain is so much faster. It has 69,000 TPS, right? I think, again, this kind of, it's a bad comparison because you're comparing these very raw payments of just transferring value from A to B with Visa, which is this very, very complex, very bundled payment solution. And then also, perhaps more importantly for the argument here, is there should be a subset of payments where this doesn't matter right so if i do a one million dollar transaction and there are hundreds of thousands of these happening every day or millions maybe even well definitely millions then it shouldn't matter whether i'm you know using bitcoin um which is slow and relatively expensive. But by the way, what do you think, what are current Bitcoin fees today? If I want to send $1 million to another country, what's the fee on Bitcoin in dollars? Any guesses? Yeah, $1. Yeah, that's not much. You can't do that in Tratva. You can't send $1 million to another country with one buck. You can't do that. Not in that order of magnitude, right? So clearly there should be some subset of payments where it would be more efficient to already use Bitcoin, something as simple as Bitcoin, as the kind of international settlement thing. This is especially true for rare international pairs where normally you would be doing many hops between banks, so the way a TradFi international payment works is you're sending it kind of they're exchanging these IOUs and they have these very custom agreements between each other to trust each other with these IOUs. So when you're sending, let's say, money from Armenia to Chile, it might very well be the case that this payment is going to do five or six hops across the world. So first to a more local bank, and then to another one, maybe then to some US bank, and then finally to some Latin bank, and then finally to Chile. In the meantime, you don't know where the payment is and the fees you don't know how much each intermediary is going to collect. So already this should be more, even with Bitcoin, something as primitive as Bitcoin, like V1 of blockchains, it should be more efficient. But guess what? Here's my startup idea. Why don't we do a TransferWise but with Bitcoin rails? So the way TransferWise works is you have these bank accounts in different countries, and then they kind of just internally settle the payment. So they front it for you. They receive it in one country, then they front it to you in the other country. Well, here's the problem. For that to happen, you would need two banks to agree not to ban you for your Bitcoin payments. So if you can convince two banks not to ban you because you're not fitting their AML requirements or they don't know what you're doing or they're just scared of Bitcoin or they think it's like some shady thing, then you might as well just have a normal, very classical IOU-type contract with these guys to just do a normal settlement. So if you've identified this pair where there's a lot of sudden trade happening, and it's not been captured yet, let's say, I don't know, Chileans suddenly get obsessed about Ethiopian coffee, if suddenly there's a lot of trade happening, immediately there will be someone who will try to capture those flows to avoid all these inefficiencies with these hops, right? And you can do so with IOUs for these large transactions. So this very convincing narrative, like when you hear it for the first time, oh yeah, sure, let's use crypto rails just for the international part, is actually maybe not as strong for these larger B2B transactions, especially when it comes to global supply chains. Cool. Another narrative, privacy. Well, we can't penetrate the whole market unless we have privacy. Obviously, if I go somewhere and I buy my coffee, I don't want to broadcast that to literally the entire world that I just bought a pumpkin spice latte. That's extremely embarrassing, and I don't want other people to know. I think, well, again, that does not much for the just Rails thesis, because you could have some kind of company that wraps Monero or Zcash or some other solution and makes it into a nice payment thing. But also you could just obfuscate using centralized means, right? And that hasn't popped up yet. We've not truly challenged payments that way. So I don't think that's the main blocker. Okay, another very, very common one. So stablecoins. Very, very hot topic right now. Stablecoins have found PMF, product market fit, mostly as collateral for DeFi stuff, right? They haven't necessarily, or at least early on, they haven't found PMF for payments. We haven't seen that much action in terms of stablecoin payments. It's changing now. I think there's this emerging, very nascent stable coin payments market, which is extremely exciting. But that's also not the main blocker for the crypto rail thesis, because, I mean, if I'm just using it for one hop, so I'm selling my whatever, Polo Slotties here, and then sending them over to Brazil, then it's just one hop over Bitcoin. The next block, I'm already selling it. So the fluctuation of the value doesn't matter too much. And also, it's just false that you can't make payments with a highly volatile currency, right? Like hundreds of countries have, or dozens of countries have highly volatile currencies, and yet somehow people get paid and have salaries and so on. So another thesis, accounts, right? So here the idea is that we need something like account abstraction for mass adoption, better onboarding, stuff like account recovery, more granular permissions. If you think about it, it's kind of crazy that I need exactly the same level of permissions to send $1 and to send $1 million. But again, there should be some subset of payments where all of this doesn't matter because we do have these professionalised custodians we can have like for larger B2b payments we could have all of that so What's needed to unlock? these Payments for everyone to have this peer-to-peer cash that is fully on chain. So I'd like to argue that it's As simple as interoperability with everything else. So I Mentioned early on this guy who was going around garages trying to convince them, hey, adopt our coin for parking fees, and unfortunately they weren't very successful. Well, because it wasn't interoperable with standard ways of paying for parking. So here's the thesis. Interoperability is a necessary condition for interchangeability, which makes money, right? Like, money has to be spendable, which in turn is a necessary condition for any new payment network. So essentially, the idea of bootstrapping a whole payment network from scratch is kind of like that won't work right so what does this mean in practice so in practice this means that we need to slightly defragment parts of our current ecosystem so this is an example from I think a year ago blog post by Vitalik he posed the problem, hey, I have coins on Scrawl, but I want to pay on Tyco. What do I do? Super annoying. If I want USDC, 10 USDC on Optimism, you want 10 USDT on Arbitrum. Super annoying. Another one is, maybe I have some stable coins, but you want fiat. That's a problem we recently asked how we could solve that. And this is what I mean by interoperability. So making it such that it's not one chain, one token, but any chain, any token, and even fiat crypto. So we have a November challenge, which is the no-sex challenge to avoid using centralized exchanges for a whole month. If you want to hit me up, I can share the details later. But back to this idea, how can we achieve this interoperability? Well, it's really, really hard because not all blockchains talk to each other very well. And also fiat and crypto doesn't talk to each other very well. So there needs to be some layers of abstraction that let all of this get routed correctly. And I think one approach is to lock up the funds and then let them be routed where they need to go. And this is something we've been researching for the past one and a half years. But also, I'd like to very briefly mention that it might be the case that payments are currently being eaten by Visa and MasterCard. Crypto payments are being eaten by that because there's this huge emergence of cards, of crypto cards, which I'm using too, by the way. I think they're extremely convenient and a great tool. But we also need to ask ourselves, well, maybe we can skip that step, right? Maybe we can somehow be interoperable in such a way that the merchant receives this raw, simple payment without all of these extra things like the rewards, points, chargebacks, because not for all payment types they're needed, right? So maybe we need to unbundle the payment a little bit. As one of the final notes, I'd like to, this is a quote I found when I was researching for this presentation and it's from 2014. And this was from someone from the Bitcoin Foundation and essentially she said that you can send money over the internet, which is super useful for especially the unbanked, right? So maybe the, it's really interesting for me to see that this was the narrative 10 years ago, and still it's a really, really important part of what we're doing. So, to summarize, we have briefly discussed scalability, where we discovered that for some subset of payments, it shouldn't matter. But if it doesn't matter for these payments, you need these banks to anyway agree, then you might as well go directly through the banks and not use the crypto rails. We've discovered the benefits of account abstraction and easy onboarding for like a mass payment. We briefly discussed stablecoins and what role they could play in the payment space. Then we briefly discussed privacy and the needs there, and, like, is it going to happen? And then, finally, we discussed what interoperability means on a technical level, but I'd also like to briefly touch on the regulatory level, where, essentially, by having regulatory clarity, we can convince more and more of these stratify institutions to be, well, interoperable with our payment systems. So, yeah, long story short, I strongly believe that the next generation of banks will simply skip the neobank stage. So if you think about the Western world, we had traditional banks, then we had Revolut, Monzo, and so on. I think in a lot of emergent economies, we'll simply skip that stage, and the next generation of banks will be partially on-chain banks that are interoperable with TradFi. Yeah. If you want to talk payments, if you want to exchange memes, please DM me. These are my details. Yeah. Open to questions. Alright. Okay. And now we come to the Q&A session. You guys see the QR code on the screen? Any questions for the speaker? Please scan. Okay. Here we go, man. The first one coming. All right. What are your thoughts on agents using stable coins for online purchases? And agents, agent to agents, that's the dead thing, I guess, human payments. Let's go. Yes. Let's do it. I mean, I think, you know, the idea of Intents is much, much broader than just Intents for a swap or a cross-chain swap. Intents can be, you know, just orders for something, and I can just express something like, hey, I want a pizza for so and so many Bitcoin, and someone should be able to go around the world, whether that's a human or an autonomous, well, a bot or AI agent, and solve that for me, right? I think that's clearly something that will happen where all these searches will be done by bots. All right, we have a second question. Second question. Is privacy a blocker for widespread adoption? Yes, but also we don't have widespread adoption yet. So if you think about your payments that you've made, probably this week you've made several dozen payments for coffees, Ubers, maybe to your landlord, maybe you've received a salary that were not on chain. And privacy, yeah, simply, it's too small of a percentage of payments to matter in a big way. So I think it will be a huge problem and will be a blocker, but just not yet. And we have a path forward, right? Like we know how to at least have soft privacy without getting jailed. More questions coming. All right, there's a third one right there. How important is financial literacy? I think hugely important in emergent economies, right? So if you think about emergent economies, the financial products that they have access to, that normal people have access to, are extremely primitive. A lot of people are still saving their salaries in dollars rather than, I don't know, something like the S&P 500 or Ethereum. And they simply don't have access to more sophisticated financial products. All of this will need a lot of education. But for now, I think also we can make more sophisticated financial products accessible to emerging economies through crypto. And we have the fourth question. Can monopolies do anything? Well, yeah, that's a very, very good question. I think the main challenge right now is that Visa and Mastercard have a very, very lucrative reward system, which the merchants pay for, right? So if you think about a credit card payment versus a debit card payment, if you're using a credit card and you're getting some cash back or some other rewards, you're essentially getting subsidized by all the people who paid in cash or with a debit card. I think that's a cycle that's very, very hard to break. And that's why I think the first widespread on-chain payment system will emerge in emerging economies where penetration of Visa and MasterCard isn't that high, and we will have to build our own similar reward system, maybe some crypto-native distribution methods that high and we will have to build our own similar reward system, maybe some crypto native distribution methods like future airdrops and stuff like that might be a very good way to bootstrap a payments network. We have one minute left for the Q&A so maybe we can get this two or three questions. What specific domains or use cases for payments do you think are most promising in the near term? I think we have this incredible explosion of remote work and global work and global teams in crypto. Almost, well, the majority of teams is somehow globally distributed. Payments are frankly a pain in the butt to manage. I think we will see a huge emergence of on-chain payments that then use some kind of localized off-ramps. Yeah. Let's do the last question. Yeah. At what level is adoption? Oh, super low. I mean, we don't know, right? Well, we don't know, because it's very hard to estimate, but I mean, it's definitely sub 1%, and if you account for all payments, and probably sub 0.1%. All right, all right. Thank you, you guys. A big applause to the Urban, please.", "eventId": "devcon-7", - "slot_start": 1731480600000, - "slot_end": 1731481200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs" + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY", + "resources_slides": null, + "speakers": [ + "konrad-urban" + ] }, "vector": [ 0, @@ -845856,6 +846552,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -846404,9 +847101,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -846483,6 +847177,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -846572,6 +847267,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -846855,6 +847551,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -846884,6 +847581,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -846990,10 +847688,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -847007,48 +847705,51 @@ 0, 0, 0, - 0, 0 ] }, { "session": { - "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks", - "sourceId": "NL3A7T", - "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs", - "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "western-liberalism-to-world-liberalism", + "sourceId": "H8N9CP", + "title": "Western liberalism to world liberalism", + "description": "Western liberalism to world liberalism", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "ZKPs", - "Security" + "liberalism" ], "tags": [ - "Security" + "Ethereum for Good", + "Free Speech", + "Network State" ], "language": "en", "speakers": [ - "stefanos-chaliasos" + "diego-fernandez", + "bruno-macaes", + "vitalik-buterin", + "afra-zhao-wang", + "ahmed-gatnash" ], "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc" + "slot_start": 1731654000000, + "slot_end": 1731657600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw" }, "vector": [ - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -847236,6 +847937,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847478,6 +848180,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847559,6 +848262,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847573,6 +848277,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847616,6 +848321,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847755,7 +848461,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -847779,9 +848484,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -847807,6 +848509,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -847826,6 +848529,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -847904,6 +848608,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -848345,12 +849050,10 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -848363,42 +849066,39 @@ }, { "session": { - "id": "what-is-the-status-of-epbs-and-its-future-iterations", - "sourceId": "3MUYVQ", - "title": "What is the status of ePBS and its future iterations", - "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "what-defi-founders-can-learn-from-web2", + "sourceId": "QB8CGR", + "title": "What DeFi Founders Can Learn From Web2", + "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", "featured": false, "doNotRecord": false, "keywords": [ - "PBS", - "consensus", - "fork-choice" - ], - "tags": [ - "PBS", - "fork", - "choice", - "PBS" + "Metrics", + "Unit economics", + "Growth" ], + "tags": [], "language": "en", "speakers": [ - "potuz" + "mike-silagadze" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU" + "slot_start": 1731480600000, + "slot_end": 1731481200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs" }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -849107,10 +849807,50 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -849172,7 +849912,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -849360,26 +850099,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, @@ -849682,30 +850401,10 @@ 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, @@ -849717,51 +850416,39 @@ }, { "session": { - "id": "whats-going-into-the-pectra-upgrade", - "sourceId": "9WTJRX", - "title": "What’s Going Into the Pectra Upgrade?", - "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.", - "track": "Core Protocol", + "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks", + "sourceId": "NL3A7T", + "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs", + "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.", + "track": "Security", "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "fork", - "hard" - ], "keywords": [ - "Pectra", - "Governance", - "Hard forks" + "ZKPs", + "Security" + ], + "tags": [ + "Security" ], - "duration": 1515, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "ufIDBCgdGwY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt", - "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...", - "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731393000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc", - "resources_slides": null, "speakers": [ - "christine-kim" - ] + "stefanos-chaliasos" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc" }, "vector": [ + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -850496,6 +851183,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -850721,7 +851410,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -851039,7 +851727,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -851062,10 +851749,12 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, - 2, 0, 0, 0, @@ -851078,47 +851767,48 @@ }, { "session": { - "id": "white-rabbit-world-premiere", - "sourceId": "7CFGTS", - "title": "White Rabbit World Premiere", - "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes", - "track": "Entertainment", - "type": "Music", - "expertise": "Beginner", - "audience": "Design", + "id": "what-is-the-status-of-epbs-and-its-future-iterations", + "sourceId": "3MUYVQ", + "title": "What is the status of ePBS and its future iterations", + "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "animation", - "film", - "nft" + "PBS", + "consensus", + "fork-choice" ], "tags": [ - "Account", - "Abstraction" + "PBS", + "fork", + "choice", + "PBS" ], "language": "en", "speakers": [ - "pplpleasr" + "potuz" ], "eventId": "devcon-7", - "slot_start": 1731497400000, - "slot_end": 1731500100000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc" + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -851887,6 +852577,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -852076,6 +852767,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -852390,9 +853082,6 @@ 0, 0, 0, - 0, - 0, - 2, 2, 0, 0, @@ -852410,10 +853099,14 @@ 0, 0, 0, + 0, 2, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -852423,58 +853116,48 @@ 0, 0, 0, - 2, 0, 0 ] }, { "session": { - "id": "who-needs-a-wallet-anyway", - "sourceId": "ZZKKRZ", - "title": "Who needs a wallet anyway?", - "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.", - "track": "Usability", - "type": "Lightning Talk", + "id": "whats-going-into-the-pectra-upgrade", + "sourceId": "9WTJRX", + "title": "What’s Going Into the Pectra Upgrade?", + "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "tags": [ - "Permissionless", - "Developer Infrastructure", - "Decentralization", - "Environment", - "User Experience", - "trusted", - "wallet", - "execution", - "Developer Infrastructure", - "Permissionless", - "User Experience" + "fork", + "hard" ], "keywords": [ - "Trusted", - "Execution", - "Environments" + "Pectra", + "Governance", + "Hard forks" ], - "duration": 555, + "duration": 1515, "language": "en", - "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83", - "sources_youtubeId": "iNLHWc5toYo", + "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f", + "sources_youtubeId": "ufIDBCgdGwY", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt", - "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.", + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt", + "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...", "eventId": "devcon-7", - "slot_start": 1731393600000, - "slot_end": 1731394200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg", + "slot_start": 1731391200000, + "slot_end": 1731393000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc", "resources_slides": null, "speakers": [ - "itai-turbahn" + "christine-kim" ] }, "vector": [ @@ -852482,12 +853165,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -853232,7 +853914,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -853270,7 +853951,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853318,7 +853998,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853388,7 +854067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853408,10 +854086,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -853453,6 +854129,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -853582,7 +854259,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853644,7 +854320,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853770,6 +854445,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -853780,7 +854463,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -853789,6 +854471,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -853800,40 +854484,38 @@ }, { "session": { - "id": "who-wins-ethereum-block-building-auctions-and-why", - "sourceId": "VKQ8NC", - "title": "Who Wins Ethereum Block Building Auctions and Why?", - "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "white-rabbit-world-premiere", + "sourceId": "7CFGTS", + "title": "White Rabbit World Premiere", + "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes", + "track": "Entertainment", + "type": "Music", + "expertise": "Beginner", + "audience": "Design", "featured": false, "doNotRecord": false, "keywords": [ - "MEV", - "PBS", - "Block Auction" + "animation", + "film", + "nft" ], "tags": [ - "blocks", - "auction" + "Account", + "Abstraction" ], "language": "en", "speakers": [ - "danning-sui", - "burak-oz" + "pplpleasr" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI" + "slot_start": 1731497400000, + "slot_end": 1731500100000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc" }, "vector": [ 0, 0, - 6, 0, 0, 0, @@ -853841,6 +854523,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -854549,8 +855232,6 @@ 0, 0, 0, - 0, - 6, 6, 0, 0, @@ -854716,7 +855397,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -854897,7 +855577,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -855120,6 +855799,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -855131,7 +855813,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -855148,35 +855829,60 @@ 0, 0, 0, + 0, + 2, + 0, 0 ] }, { "session": { - "id": "why-defi-matters-on-ethereum", - "sourceId": "E7GFJC", - "title": "Why DeFi matters on Ethereum", - "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "", + "id": "who-needs-a-wallet-anyway", + "sourceId": "ZZKKRZ", + "title": "Who needs a wallet anyway?", + "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "tascha", - "loi-luu", - "kain-warwick", - "namik-muduroglu" + "tags": [ + "Permissionless", + "Developer Infrastructure", + "Decentralization", + "Environment", + "User Experience", + "trusted", + "wallet", + "execution", + "Developer Infrastructure", + "Permissionless", + "User Experience" + ], + "keywords": [ + "Trusted", + "Execution", + "Environments" ], + "duration": 555, + "language": "en", + "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83", + "sources_youtubeId": "iNLHWc5toYo", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt", + "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.", "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731582000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU" + "slot_start": 1731393600000, + "slot_end": 1731394200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg", + "resources_slides": null, + "speakers": [ + "itai-turbahn" + ] }, "vector": [ 0, @@ -855185,10 +855891,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -855405,7 +856110,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -855901,10 +856605,6 @@ 0, 0, 6, - 6, - 6, - 0, - 0, 0, 0, 0, @@ -855940,6 +856640,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -855977,6 +856678,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856024,6 +856726,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856093,6 +856796,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856112,10 +856816,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -856284,6 +856990,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856345,6 +857052,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856482,7 +857190,6 @@ 0, 2, 0, - 0, 2, 0, 0, @@ -856501,51 +857208,45 @@ }, { "session": { - "id": "why-erc-7683-is-broken-and-how-to-fix-it", - "sourceId": "YT3SSN", - "title": "Why ERC 7683 is broken and how to fix it", - "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented", - "track": "Layer 2", + "id": "who-wins-ethereum-block-building-auctions-and-why", + "sourceId": "VKQ8NC", + "title": "Who Wins Ethereum Block Building Auctions and Why?", + "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.", + "track": "Cryptoeconomics", "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "chain-abstraction", - "intents" + "MEV", + "PBS", + "Block Auction" ], "tags": [ - "Appchains", - "Cross-L2", - "Token bridging", - "Accessibility", - "erc-7683", - "intent", - "Accessibility", - "Appchains", - "Cross-L2", - "Token bridging" + "blocks", + "auction" ], "language": "en", "speakers": [ - "vaibhav-chellani" + "danning-sui", + "burak-oz" ], "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, + "slot_start": 1731558600000, + "slot_end": 1731560400000, "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg" + "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -857258,11 +857959,13 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -857336,7 +858039,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -857423,6 +858125,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -857449,7 +858153,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -857476,10 +858179,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -857824,7 +858525,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -857842,8 +858544,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -857860,38 +858562,30 @@ }, { "session": { - "id": "why-i-hate-on-chain-token-governance-and-you-should-too", - "sourceId": "8GCGZW", - "title": "Why I Hate On Chain Token Governance & You Should Too 😺", - "description": "Ethereum heavily utilizes it's strong social layer for protocol governance decisions. In recent years, we have seen projects try on chain token holder governance to make upgrades. This is a dangerous path and has proven itself to be susceptible to oligarchies and collusion. There is hope in the form of on chain token signaling with non-binding resolutions that are then executed by a trusted committee. Don't worry, I won't only be bitching about on chain governance with no solutions.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "id": "why-defi-matters-on-ethereum", + "sourceId": "E7GFJC", + "title": "Why DeFi matters on Ethereum", + "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "token voting", - "on chain governance" - ], - "tags": [ - "Core Protocol", - "Protocol Design", - "Governance", - "onchain", - "Core Protocol", - "Governance", - "Protocol Design" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "hudson-jameson" + "tascha", + "loi-luu", + "kain-warwick", + "namik-muduroglu" ], "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731492000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1mTXnRa95nn1RwpyKujvweKeIEv-zBWW4Spl__Bd7rv0" + "slot_start": 1731578400000, + "slot_end": 1731582000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU" }, "vector": [ 0, @@ -857900,12 +858594,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -858120,6 +858814,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -858180,7 +858875,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -858616,6 +859310,10 @@ 0, 0, 0, + 6, + 6, + 6, + 0, 0, 0, 0, @@ -858651,7 +859349,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -858678,7 +859375,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -858728,7 +859424,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -859055,7 +859750,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -859211,39 +859905,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "why-many-deployed-snarks-are-extremely-risky", - "sourceId": "BVSHEA", - "title": "Why many deployed SNARKs are extremely risky", - "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.", - "track": "Applied Cryptography", + "id": "why-erc-7683-is-broken-and-how-to-fix-it", + "sourceId": "YT3SSN", + "title": "Why ERC 7683 is broken and how to fix it", + "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented", + "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Concrete", - "security" + "chain-abstraction", + "intents" ], "tags": [ - "Cryptography", - "Security", - "SNARK" + "Appchains", + "Cross-L2", + "Token bridging", + "Accessibility", + "erc-7683", + "intent", + "Accessibility", + "Appchains", + "Cross-L2", + "Token bridging" ], "language": "en", "speakers": [ - "pratyush-ranjan-tiwari" + "vaibhav-chellani" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731646800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM" + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg" }, "vector": [ 0, @@ -859253,9 +859955,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -859971,20 +860670,14 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -859997,7 +860690,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -860055,6 +860747,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -860167,6 +860860,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -860195,8 +860889,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -860265,7 +860961,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -860321,6 +861016,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -860539,6 +861235,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -860546,7 +861245,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -860555,6 +861253,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -860568,46 +861271,38 @@ }, { "session": { - "id": "why-vpns-are-scams-and-what-to-do-about-it", - "sourceId": "TRMC3L", - "title": "Why VPNs are scams and what to do about it", - "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.", - "track": "Cypherpunk & Privacy", + "id": "why-i-hate-on-chain-token-governance-and-you-should-too", + "sourceId": "8GCGZW", + "title": "Why I Hate On Chain Token Governance & You Should Too 😺", + "description": "Ethereum heavily utilizes it's strong social layer for protocol governance decisions. In recent years, we have seen projects try on chain token holder governance to make upgrades. This is a dangerous path and has proven itself to be susceptible to oligarchies and collusion. There is hope in the form of on chain token signaling with non-binding resolutions that are then executed by a trusted committee. Don't worry, I won't only be bitching about on chain governance with no solutions.", + "track": "Coordination", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "censorship", - "resistance", - "Decentralization", - "Privacy", - "Use Cases" - ], "keywords": [ - "VPNs", - "mixnets", - "censorship-resistance" + "token voting", + "on chain governance" + ], + "tags": [ + "Core Protocol", + "Protocol Design", + "Governance", + "onchain", + "Core Protocol", + "Governance", + "Protocol Design" ], - "duration": 538, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "4Ir-fptXPr8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt", - "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.", - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731390000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4", - "resources_slides": null, "speakers": [ - "harry-halpin" - ] + "hudson-jameson" + ], + "eventId": "devcon-7", + "slot_start": 1731491400000, + "slot_end": 1731492000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1mTXnRa95nn1RwpyKujvweKeIEv-zBWW4Spl__Bd7rv0" }, "vector": [ 0, @@ -860615,13 +861310,13 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -860896,6 +861591,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -861243,7 +861939,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -861368,6 +862063,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -861394,6 +862090,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -861427,7 +862124,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -861444,13 +862140,14 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -861465,7 +862162,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -861771,6 +862467,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -861897,8 +862594,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -861910,13 +862605,14 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -861932,10 +862628,10 @@ }, { "session": { - "id": "wizard-build-your-own-p-iop-protocol-in-15-min", - "sourceId": "W78CYD", - "title": "Wizard: build your own P-IOP protocol in 15 min!", - "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.", + "id": "why-many-deployed-snarks-are-extremely-risky", + "sourceId": "BVSHEA", + "title": "Why many deployed SNARKs are extremely risky", + "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.", "track": "Applied Cryptography", "type": "Talk", "expertise": "Intermediate", @@ -861943,26 +862639,23 @@ "featured": false, "doNotRecord": false, "keywords": [ - "Polynomial-IOP" + "Concrete", + "security" ], "tags": [ - "Protocol Design", - "Frameworks", - "SNARK", - "polynomial-iop", - "Frameworks", - "Protocol Design", + "Cryptography", + "Security", "SNARK" ], "language": "en", "speakers": [ - "alexandre-belling" + "pratyush-ranjan-tiwari" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, + "slot_start": 1731645000000, + "slot_end": 1731646800000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo" + "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM" }, "vector": [ 0, @@ -862704,6 +863397,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -862716,6 +863410,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -862749,7 +863446,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -862808,7 +863504,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -863254,7 +863949,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -863287,31 +863981,48 @@ }, { "session": { - "id": "wmb-81321", - "sourceId": "S8MPDK", - "title": "WMB 81321", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", + "id": "why-vpns-are-scams-and-what-to-do-about-it", + "sourceId": "TRMC3L", + "title": "Why VPNs are scams and what to do about it", + "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "tags": [ + "censorship", + "resistance", + "Decentralization", + "Privacy", + "Use Cases" + ], + "keywords": [ + "VPNs", + "mixnets", + "censorship-resistance" + ], + "duration": 538, "language": "en", - "speakers": [], + "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6", + "sources_youtubeId": "4Ir-fptXPr8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt", + "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.", "eventId": "devcon-7", - "slot_start": 1731661200000, - "slot_end": 1731664800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ" + "slot_start": 1731389400000, + "slot_end": 1731390000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4", + "resources_slides": null, + "speakers": [ + "harry-halpin" + ] }, "vector": [ - 0, - 0, - 0, - 0, 0, 0, 0, @@ -863946,6 +864657,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -864129,6 +864841,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864151,6 +864864,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864165,6 +864879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864596,8 +865311,8 @@ 0, 0, 0, - 0, - 0, + 2, + 2, 0, 0, 0, @@ -864612,6 +865327,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -864630,35 +865346,37 @@ }, { "session": { - "id": "working-together-with-unity-blazor-nethereum-and-mud", - "sourceId": "SDUYDQ", - "title": "Working together with Unity, Blazor, Nethereum and MUD", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "wizard-build-your-own-p-iop-protocol-in-15-min", + "sourceId": "W78CYD", + "title": "Wizard: build your own P-IOP protocol in 15 min!", + "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.", + "track": "Applied Cryptography", "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Nethereum", - "MUD", - "Unity" + "Polynomial-IOP" ], "tags": [ - "Architecture", + "Protocol Design", "Frameworks", - "Gaming" + "SNARK", + "polynomial-iop", + "Frameworks", + "Protocol Design", + "SNARK" ], "language": "en", "speakers": [ - "juan-blanco" + "alexandre-belling" ], "eventId": "devcon-7", - "slot_start": 1731568500000, - "slot_end": 1731570000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q" + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo" }, "vector": [ 0, @@ -864671,8 +865389,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -865388,22 +866104,9 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -865504,34 +866207,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -865548,6 +866223,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -865724,6 +866400,38 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -865965,11 +866673,22 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -865983,41 +866702,25 @@ }, { "session": { - "id": "wtf-are-based-rollups-and-preconfs", - "sourceId": "UG79AE", - "title": "Wtf are based rollups and preconfs?", - "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Developer", + "id": "wmb-81321", + "sourceId": "S8MPDK", + "title": "WMB 81321", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Based Rollup", - "Preconfirmations", - "Sequencing" - ], - "tags": [ - "Validator Experience", - "Layer 2s", - "Rollups", - "sequencer", - "preconfs", - "pre-confirmations", - "Layer 2s", - "Rollups", - "Validator Experience" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "jason-vranek" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731642600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y" + "slot_start": 1731661200000, + "slot_end": 1731664800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ" }, "vector": [ 0, @@ -866027,6 +866730,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -866748,7 +867453,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -866796,11 +867500,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -866824,7 +867525,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -866871,8 +867571,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -867322,13 +868020,19 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, 2, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -867342,37 +868046,35 @@ }, { "session": { - "id": "wtf-is-the-pessimistic-proof", - "sourceId": "DAZLVG", - "title": "WTF is the pessimistic proof", - "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.", - "track": "Layer 2", - "type": "Lightning Talk", + "id": "working-together-with-unity-blazor-nethereum-and-mud", + "sourceId": "SDUYDQ", + "title": "Working together with Unity, Blazor, Nethereum and MUD", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "aggLayer", - "shared liquidity" + "Nethereum", + "MUD", + "Unity" ], "tags": [ - "ZKP", - "liquidity", - "shared", - "agglayer", - "ZKP" + "Architecture", + "Frameworks", + "Gaming" ], "language": "en", "speakers": [ - "ignasi-ramos", - "jesus" + "juan-blanco" ], "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731654600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q" + "slot_start": 1731568500000, + "slot_end": 1731570000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q" }, "vector": [ 0, @@ -867382,12 +868084,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -867879,7 +868581,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -868041,7 +868742,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -868105,6 +868805,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -868177,6 +868878,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -868188,7 +868890,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -868197,7 +868898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -868221,11 +868921,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -868665,8 +869370,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -868697,34 +869400,41 @@ }, { "session": { - "id": "yeomenai-elevate-your-game", - "sourceId": "WLKTYW", - "title": "Yeomen.ai - Elevate your game!", - "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", + "id": "wtf-are-based-rollups-and-preconfs", + "sourceId": "UG79AE", + "title": "Wtf are based rollups and preconfs?", + "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.", + "track": "Layer 2", + "type": "Lightning Talk", "expertise": "Beginner", "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Analytics", - "Modding" + "Based Rollup", + "Preconfirmations", + "Sequencing" ], "tags": [ - "Autonomous World", - "Developer Infrastructure" + "Validator Experience", + "Layer 2s", + "Rollups", + "sequencer", + "preconfs", + "pre-confirmations", + "Layer 2s", + "Rollups", + "Validator Experience" ], "language": "en", "speakers": [ - "rohan-abraham", - "roshan-abraham" + "jason-vranek" ], "eventId": "devcon-7", - "slot_start": 1731582300000, - "slot_end": 1731583800000, + "slot_start": 1731642000000, + "slot_end": 1731642600000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU" + "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y" }, "vector": [ 0, @@ -868734,12 +869444,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -869457,9 +870167,6 @@ 0, 0, 6, - 6, - 0, - 0, 0, 0, 0, @@ -869507,8 +870214,11 @@ 0, 0, 0, + 2, 0, 0, + 2, + 2, 0, 0, 0, @@ -869519,7 +870229,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -869533,6 +870242,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -869575,11 +870285,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -870049,35 +870760,37 @@ }, { "session": { - "id": "yeomenai-mud-day-demo", - "sourceId": "7DGLCG", - "title": "Yeomen.ai - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "wtf-is-the-pessimistic-proof", + "sourceId": "DAZLVG", + "title": "WTF is the pessimistic proof", + "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.", + "track": "Layer 2", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "aggLayer", + "shared liquidity" + ], "tags": [ - "Tooling", - "Gaming", - "Autonomous World", - "analytics", - "Autonomous World", - "Gaming", - "Tooling" + "ZKP", + "liquidity", + "shared", + "agglayer", + "ZKP" ], "language": "en", "speakers": [ - "rohan-abraham" + "ignasi-ramos", + "jesus" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731558900000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y" + "slot_start": 1731654000000, + "slot_end": 1731654600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q" }, "vector": [ 0, @@ -870087,12 +870800,14 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -870582,6 +871297,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -870744,6 +871460,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -870809,7 +871526,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -870839,7 +871555,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -870891,8 +871606,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -870901,6 +871616,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -870928,9 +871644,6 @@ 0, 0, 0, - 2, - 2, - 0, 0, 0, 0, @@ -871371,6 +872084,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -871379,6 +872094,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -871388,8 +872104,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -871402,33 +872116,34 @@ }, { "session": { - "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy", - "sourceId": "LUKWAM", - "title": "You know what’s going to get us from web2 to web3? Therapy", - "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "id": "yeomenai-elevate-your-game", + "sourceId": "WLKTYW", + "title": "Yeomen.ai - Elevate your game!", + "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "thriving", - "mental health", - "future" + "Analytics", + "Modding" ], "tags": [ - "future" + "Autonomous World", + "Developer Infrastructure" ], "language": "en", "speakers": [ - "simona-pop" + "rohan-abraham", + "roshan-abraham" ], "eventId": "devcon-7", - "slot_start": 1731487800000, - "slot_end": 1731488400000, + "slot_start": 1731582300000, + "slot_end": 1731583800000, "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA" + "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU" }, "vector": [ 0, @@ -871442,8 +872157,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -871641,7 +872356,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -872162,6 +872876,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -872223,6 +872939,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -872278,6 +872995,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -872735,14 +873453,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -872753,25 +873469,35 @@ }, { "session": { - "id": "your-intuition-antoine-flute-and-didgeridoo", - "sourceId": "B8SMVZ", - "title": "Your intuition Antoine flute and didgeridoo", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "yeomenai-mud-day-demo", + "sourceId": "7DGLCG", + "title": "Yeomen.ai - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [], + "tags": [ + "Tooling", + "Gaming", + "Autonomous World", + "analytics", + "Autonomous World", + "Gaming", + "Tooling" + ], "language": "en", - "speakers": [], + "speakers": [ + "rohan-abraham" + ], "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731391200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY" + "slot_start": 1731558600000, + "slot_end": 1731558900000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y" }, "vector": [ 0, @@ -872783,13 +873509,10 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -873507,6 +874230,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -873536,6 +874260,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -873587,6 +874312,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -873623,6 +874349,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -874078,11 +874806,10 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -874096,49 +874823,38 @@ }, { "session": { - "id": "zero-to-dapp", - "sourceId": "LUW7G9", - "title": "Zero To Dapp", - "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Developer", + "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy", + "sourceId": "LUKWAM", + "title": "You know what’s going to get us from web2 to web3? Therapy", + "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Onboarding" + "thriving", + "mental health", + "future" ], "tags": [ - "Layer 1", - "Layer 2s", - "Tooling", - "DevRel", - "Live Coding", - "onboarding", - "DevRel", - "Layer 1", - "Layer 2s", - "Live Coding", - "Tooling" + "future" ], "language": "en", "speakers": [ - "simon-emanuel-schmid", - "rob-stupay", - "abena" + "simona-pop" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk" + "slot_start": 1731487800000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA" }, "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -874147,6 +874863,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -874345,6 +875062,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -874806,7 +875528,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -874866,8 +875587,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -874888,13 +875607,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -874939,7 +875656,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -874989,7 +875705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -875047,7 +875762,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -875427,7 +876141,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -875437,7 +876150,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -875450,6 +876162,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0 @@ -875457,46 +876175,25 @@ }, { "session": { - "id": "zk-email-fast-proofs-and-production-ready-account-recovery", - "sourceId": "WNQBQH", - "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery", - "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", + "id": "your-intuition-antoine-flute-and-didgeridoo", + "sourceId": "B8SMVZ", + "title": "Your intuition Antoine flute and didgeridoo", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ZK", - "Email" - ], - "tags": [ - "Privacy", - "ZKP", - "Use cases of cryptography", - "client-side", - "2FA", - "Account Abstraction", - "Cryptography", - "Identity", - "Privacy", - "Recovery", - "Security", - "Use cases of cryptography", - "Zero-Knowledge", - "ZKP" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "aayush-gupta", - "sora-suegami" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY" + "slot_start": 1731389400000, + "slot_end": 1731391200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY" }, "vector": [ 0, @@ -875508,7 +876205,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -875614,7 +876310,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -876232,12 +876927,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -876249,8 +876942,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -876265,7 +876956,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -876286,9 +876976,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -876312,7 +877000,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -876354,7 +877041,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -876404,23 +877090,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -876787,22 +877456,51 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, - 0, 2, 0, 0, @@ -876821,37 +877519,45 @@ }, { "session": { - "id": "zk-in-rollups-full-validity-proving-on-the-op-stack", - "sourceId": "8J8Z7Q", - "title": "ZK in Rollups: Full Validity Proving on the OP Stack", - "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "zero-to-dapp", + "sourceId": "LUW7G9", + "title": "Zero To Dapp", + "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Onboarding" + ], "tags": [ + "Layer 1", "Layer 2s", - "Rollups", - "ZKP" + "Tooling", + "DevRel", + "Live Coding", + "onboarding", + "DevRel", + "Layer 1", + "Layer 2s", + "Live Coding", + "Tooling" ], "language": "en", "speakers": [ - "uma-roy" + "simon-emanuel-schmid", + "rob-stupay", + "abena" ], "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY" + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk" }, "vector": [ - 0, - 0, - 0, - 0, 0, 0, 0, @@ -877524,6 +878230,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -877583,6 +878291,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -877603,11 +878312,14 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -877628,7 +878340,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -877661,7 +878372,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -877703,6 +878413,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -877760,6 +878471,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -878139,6 +878851,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -878163,54 +878876,51 @@ 0, 0, 0, - 0, - 0, 0 ] }, { "session": { - "id": "zkmpc-bring-public-auditability-into-mpc", - "sourceId": "XNN3XR", - "title": "ZKMPC: Bring public auditability into MPC", - "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.", + "id": "zk-email-fast-proofs-and-production-ready-account-recovery", + "sourceId": "WNQBQH", + "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery", + "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.", "track": "Applied Cryptography", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, + "keywords": [ + "ZK", + "Email" + ], "tags": [ + "Privacy", "ZKP", - "MPC", - "collaboration", - "zk-snark", - "MPC", + "Use cases of cryptography", + "client-side", + "2FA", + "Account Abstraction", + "Cryptography", + "Identity", + "Privacy", + "Recovery", + "Security", + "Use cases of cryptography", + "Zero-Knowledge", "ZKP" ], - "keywords": [ - "Collaborative", - "zk-SNARKs" - ], - "duration": 1399, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "aWQ8zzi1EAQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "aayush-gupta", + "sora-suegami" + ], "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, + "slot_start": 1731468600000, + "slot_end": 1731470400000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ", - "resources_slides": null, - "speakers": [ - "task-ohmori", - "yusuke-nakae" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY" }, "vector": [ 0, @@ -878328,8 +879038,7 @@ 0, 0, 0, - 0, - 0, + 6, 0, 0, 0, @@ -878949,14 +879658,11 @@ 0, 0, 6, - 6, - 0, - 0, - 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -878968,6 +879674,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -878982,6 +879690,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -879002,7 +879711,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -879040,10 +879751,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -879072,6 +879779,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -879121,6 +879829,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -879513,9 +880222,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 2, @@ -879530,46 +880240,37 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "zkpassport-private-unforgeable-identity", - "sourceId": "K3GWST", - "title": "ZKpassport: Private Unforgeable Identity", - "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.", - "track": "Applied Cryptography", + "id": "zk-in-rollups-full-validity-proving-on-the-op-stack", + "sourceId": "8J8Z7Q", + "title": "ZK in Rollups: Full Validity Proving on the OP Stack", + "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.", + "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ZK", - "NFC", - "Noir", - "PLONK" - ], + "keywords": [], "tags": [ - "Privacy", - "Identity", - "Zero-Knowledge", - "noir", - "Identity", - "Privacy", - "Zero-Knowledge" + "Layer 2s", + "Rollups", + "ZKP" ], "language": "en", "speakers": [ - "michael-elliot", - "theo-madzou" + "uma-roy" ], "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731486000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U" + "slot_start": 1731582600000, + "slot_end": 1731583800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY" }, "vector": [ 0, @@ -879579,10 +880280,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -879746,10 +880447,8 @@ 0, 0, 0, - 6, 0, 0, - 6, 0, 0, 0, @@ -880309,6 +881008,23 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -880322,7 +881038,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -880339,6 +881054,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -880368,6 +881087,35 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -880409,7 +881157,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -880427,7 +881174,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -880828,9 +881574,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -880843,6 +881591,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "zkmpc-bring-public-auditability-into-mpc", + "sourceId": "XNN3XR", + "title": "ZKMPC: Bring public auditability into MPC", + "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "ZKP", + "MPC", + "collaboration", + "zk-snark", + "MPC", + "ZKP" + ], + "keywords": [ + "Collaborative", + "zk-SNARKs" + ], + "duration": 1399, + "language": "en", + "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188", + "sources_youtubeId": "aWQ8zzi1EAQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ", + "resources_slides": null, + "speakers": [ + "task-ohmori", + "yusuke-nakae" + ] + }, + "vector": [ 0, 0, 0, @@ -880853,6 +881649,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -880872,11 +881669,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -880889,53 +881684,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zkproving-the-history-of-ethereum-in-real-time", - "sourceId": "TVNJ99", - "title": "zkProving the history of Ethereum in real time.", - "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Lightclient", - "type1", - "STARK" - ], - "tags": [ - "ZK-EVMs", - "ZKP", - "Zero-Knowledge", - "lightclient", - "type1", - "starks", - "Zero-Knowledge", - "ZK-EVMs", - "ZKP" - ], - "language": "en", - "speakers": [ - "jordi-baylina" - ], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -881234,7 +881986,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -881624,6 +882375,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -881681,7 +882434,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -881701,6 +882453,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -881714,6 +882467,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -881744,7 +882500,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -882017,7 +882772,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -882181,6 +882935,85 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zkpassport-private-unforgeable-identity", + "sourceId": "K3GWST", + "title": "ZKpassport: Private Unforgeable Identity", + "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZK", + "NFC", + "Noir", + "PLONK" + ], + "tags": [ + "Privacy", + "Identity", + "Zero-Knowledge", + "noir", + "Identity", + "Privacy", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "michael-elliot", + "theo-madzou" + ], + "eventId": "devcon-7", + "slot_start": 1731484200000, + "slot_end": 1731486000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -882228,14 +883061,9 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -882248,47 +883076,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zoom-in-on-eof-stack-validation", - "sourceId": "YYGYGF", - "title": "Zoom in on EOF stack validation", - "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EVM", - "EOF" - ], - "tags": [ - "Core Protocol", - "eof", - "Core", - "Protocol" - ], - "language": "en", - "speakers": [ - "andrei-maiboroda" - ], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -882382,8 +883173,10 @@ 0, 0, 0, + 6, 0, 0, + 6, 0, 0, 0, @@ -882957,6 +883750,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -882993,6 +883787,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -883021,7 +883816,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -883041,9 +883835,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -883061,6 +883855,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -883314,7 +884109,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -883326,8 +884120,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -883508,6 +884300,2644 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zkproving-the-history-of-ethereum-in-real-time", + "sourceId": "TVNJ99", + "title": "zkProving the history of Ethereum in real time.", + "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Lightclient", + "type1", + "STARK" + ], + "tags": [ + "ZK-EVMs", + "ZKP", + "Zero-Knowledge", + "lightclient", + "type1", + "starks", + "Zero-Knowledge", + "ZK-EVMs", + "ZKP" + ], + "language": "en", + "speakers": [ + "jordi-baylina" + ], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 2, + 2, + 0, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zoom-in-on-eof-stack-validation", + "sourceId": "YYGYGF", + "title": "Zoom in on EOF stack validation", + "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EVM", + "EOF" + ], + "tags": [ + "Core Protocol", + "eof", + "Core", + "Protocol" + ], + "language": "en", + "speakers": [ + "andrei-maiboroda" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -884928,6 +888358,7 @@ 0, 0, 0, + 0, 2, 0, 0, diff --git a/devcon-api/data/vectors/dictionary.json b/devcon-api/data/vectors/dictionary.json index 37b8690a..e39feba0 100644 --- a/devcon-api/data/vectors/dictionary.json +++ b/devcon-api/data/vectors/dictionary.json @@ -159,8 +159,8 @@ "auryn-macmillan", "lasha", "niharika", - "rose", "richa", + "rose", "kira", "nico-rodriguez", "jonah-burian", @@ -544,9 +544,9 @@ "daniel-marzec", "garm", "agustin-grosso", - "dominik-hell", "juli-corti", "ran-hammer", + "dominik-hell", "shawn-odonaghue", "joseph-low", "hazel-devjani", @@ -617,6 +617,7 @@ "jack-sanford", "daniel-yanev", "sandeep-nailwal", + "marc-boiron", "andy", "stephane-gosselin", "wassim-z-alsindi", @@ -936,6 +937,8 @@ "system", "Permissionless", "defi", + "Ethereum Roadmap", + "Verkle trees", "Consensus Mechanisms", "execution", "tickets", @@ -979,7 +982,6 @@ "Vision", "culture", "latency", - "Ethereum Roadmap", "Not financial", "cybernetics", "dark", @@ -1061,7 +1063,6 @@ "api", "eve", "online", - "Verkle trees", "state", "expiry", "trend", From 53ccf1412e821b39cec5dbd740a76fe649dd699b Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 10:57:49 +0700 Subject: [PATCH 14/17] [skip deploy] PUT /sessions/beyond-ligero-and-brakedown-building-a-fast-prover-based-on-list-polynomial-commitments --- ...-based-on-list-polynomial-commitments.json | 27 ++++++++++++------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/beyond-ligero-and-brakedown-building-a-fast-prover-based-on-list-polynomial-commitments.json b/devcon-api/data/sessions/devcon-7/beyond-ligero-and-brakedown-building-a-fast-prover-based-on-list-polynomial-commitments.json index 3093ead0..c68405ef 100644 --- a/devcon-api/data/sessions/devcon-7/beyond-ligero-and-brakedown-building-a-fast-prover-based-on-list-polynomial-commitments.json +++ b/devcon-api/data/sessions/devcon-7/beyond-ligero-and-brakedown-building-a-fast-prover-based-on-list-polynomial-commitments.json @@ -9,10 +9,6 @@ "audience": "Academic", "featured": false, "doNotRecord": false, - "keywords": [ - "Provable", - "Security" - ], "tags": [ "Layer 2s", "Rollups", @@ -25,14 +21,27 @@ "Rollups", "Zero-Knowledge" ], - "language": "en", - "speakers": [ - "azam-soleimanian", - "bogdan-ursu" + "keywords": [ + "Provable", + "Security" ], + "duration": 1518, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "V7hmwJ-l0qY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341fe49dbb7a90e16f03c3.vtt", + "transcript_text": " Hi, everyone. So today we're going to talk about how to build provers. This is a joint talk with my colleague, Azam. And yeah, the main purpose of the talk is to see how we can use these polynomial commitments. And we're going to create something based on Ligero and Breakdown, which are two previous works. So just a quick word about us. We're both cryptography researchers at ConsenSys, and we're working in the Linear Prover team. And since you're here, you probably have been hearing all this time how to make proofs, how to make proofs, you want to make proofs, and this talk, this intermediate cryptography talk is about how to actually do that mathematically and how to construct a proof system. So we're going to dig into some details, some mathematical details, but we're going to do that hopefully in a way that carries information across to you. So just some motivation. At the high level, we're interested in how we can move from an EVM state to another one. There is the Ethereum virtual machine state transition that basically explains how that happens. And what happens in the layer two rollups is that this state transition is being arithmetized, and then we compute the proof that the state transition happened properly. And why this is useful is that not all nodes will have to perform the state transition themselves. They can just verify the proof. And since verification will be by design a very cheap operation, the overall system is going to be quite efficient. And as I already prepared you, we're going to look into how to construct such a proof system. There will be two parts in our talk. The first part will be the polynomial commitment scheme, which we call Vortex. And the second part will be how to use this polynomial commitment scheme, some other machinery, in order to reason about the VM execution. So let's dip into cryptography with polynomial commitments So basically like these two parts are the main building blocks of how to build a snark so polynomial commitments first you're going to have just a setup algorithm and At a very high level is just going to give you some public parameters so public parameters and if you want to commit you're going to use these public parameters you're going to use some polynomial you want to commit to a polynomial this polynomial will have some bounded degree K and you're going to output some commitments C and then we want to reason about this polynomial, about this commitment that we just made. And basically, we're going to look at the protocol that's interactive between a prover and a verifier. They both have access to the polynomial, to the parameters, to the commitment. And in the case of the prover also, yeah, also the polynomial, the verifier doesn't know the polynomial, only knows the commitment. And the prover basically attempts to prove that P of X is indeed equal to Y. And this happens over multiple interaction routes. Very high level, the security condition that we want to achieve is that the prover should not be able to convince the verifier in the case that he committed to something, to some polynomial that actually does not evaluate to the claimed Y. And we want to do this efficiently. We want to amortize our costs. So basically we're going to do something called batch polynomial commitments in which instead of committing to only one polynomial, we're going to commit to N of them. We're going to commit to n of them. We're going to claim n evaluations. And basically, the proof is going to be a batch proof, a combined proof, that all of these polynomials evaluate properly. And also, the verifier now knows the evaluation, the claimed evaluations. And let's look into the math that we use in order to build such a thing. These are called the Reed-Solomon codes. And without getting into the nitty gritty, we're going to use a finite field, f. If you don't know what a finite field is, just imagine integers, modulus, and prime p. And we are going to take some subset of n elements a1 to an from this finite field then encoding a polynomial so this is about the codes encoding a polynomial will just be evaluated the polynomial at this endpoints and in order for you to actually in order for this encoding to actually express information about the polynomial you want that the degree of P is actually smaller or equal than N in order to actually be able to express it uniquely. And in fact, you want to have, this N is going to be much higher, you want to have redundant information about the polynomial in order to error correct. And now let's look at the starting point where we took inspiration for our work, which is the Ligero breakdown protocol. These are two separate schemes, but they have a very common structure. So in this previous work, the setup algorithm would give you a hash function as the public parameters. And then in order to commit to n polynomials, what you're going to do is that you're going to first compute the encodings, the Reed-Solomon encodings of the n polynomials. Each row now corresponds to an encoding. You're going to construct this matrix, and you're going to apply a hash function on each column in order to get H1. Then you apply the hash function on the second column to get H2 and so on and this is going to be your commitment your commitment is these hashes of the columns of the encodings of your polynomials so that's how you commit and I put this here in case you forget it. Now we are so interested in how do we open, how do we actually prove to the verifier that our claimed evaluations are correct in a secure way. So basically the verifier is going to send the coin beta to the prover. The prover is going to compute, this looks like a complicated equation, but actually it's not. It's just you have each row, and each row gets multiplied with the power of beta. So it's a linear combination of the rows with this beta that comes from the verifier. This is a vector u. Send it to the verifier. The verifier now picks an index that it wants to check. It's only going to be able to check one. Send it back. And the prover replies to the column of that specific index in this case this is the first one the verifier does two checks it checks that indeed when it applies the hash function to the opened column to the one that we just revealed it is equal to the one in the commitment and it checks that indeed if you compute the linear combination of the betas with the revealed columns then you're going to get the ith coordinate of u. And this protocol is going to ensure that all the rows are indeed codewords. But we want more than this. We want to actually make a proof about the claimed evaluations of the polynomial, not just show that the rows are codewords. And what we notice in this work is that if we interpolate this vector that is sent by the prover to obtain some polynomial, and then we also check that this polynomial evaluated at x is equal to the linear combinations of the y's, if we do this additional check, we can prove that the polynomials evaluate properly and this proof can be very simple if you are in the unique decoding regime which I'm just going to talk about next the point is that if you want to opt it if you want optimal parameters the proof becomes very complicated and I'm going to give you just a flavor of why that is. So basically, when you're talking about codes, you can consider two cases. There is the unique decoding, which in this case is exemplified by this radius. This is the target vector that we want to decode. And this is a radius around it. And as you can see, if you set it this length, then there is only one code word. However, you can also consider relaxing this parameter to be able to include multiple points that are candidates for your decoding. And the proof for our polynomial commitments can become much more complicated if you want the optimal parameters, if you want to have something that's efficient in practice. So as I said, the small one is the unique decoding regime, there's only one candidate and the yellow one is the least one, multiple candidates. So the security guarantee in the that we show in the least decoding regime is that there will exist polynomials of small degree that evaluate correctly and these commitments will have only a small amount of coordinates that are different from the target commitment that we are decoding. And if you want more details for the proof of security, you can check out our ePrint. Thanks a lot. Now we're going to move to the second part of the talk, where we're looking at how can we use this polynomial commitment in conjunction with other things to reason about the EVM and I'm handing over to my colleague Azam. Thank you Bogdan. So let's go to the second part. How and here we are focusing what is happening on layer two, linear, and how we generate proof from EVM execution via such polynomial commitment. There are a lot of steps until we can generate proof. The first step in this journey is arithmetization. And arithmetization for us is mathematical modeling of EVM by columns and constraints between columns. For example, if you want to prove that a transaction had a valid signature, first you hash the signature, so you have to prove that the hash was correct. So if I want to here to show that hash of is why I start with column X and column X is a kind of describing your input X for example you can consider the byte of the X which are splitted in the cells of these columns then which with each steps of the computation that is happening in the hash, this column, you would have a new column with new values in the cell and so on until that you would arrive to column Y, which is your output. And there is constraint between this column to say that how the computation of the hash is going on so by this arithmetization here you get bunch of columns and constraint between columns there are different constraints for example it's just example here there are more lookup constraints or query we also can say which says column R is included in column B or local constraint that says okay if you have two columns then the first row of these two columns are equal global cond constraints, which are very important for us, and they are more about cells, the relation over the cells of the same column or even between several columns. I'm putting an example here for Fibonacci sequence. For this Fibonacci sequence, we know that for each cell is in fact addition of two previous cells. So you write the constraint like this. And we call this one trace, trace of execution or Fibonacci. Okay, if you want to verify this constraint as a verifier, definitely you don't want to do it like this because it's too many efforts, especially global constraints because they are over the cells constraint as a verifier. Definitely you don't want to do it like this because it's too many effort especially global constraint because they are over the cells and you have to check a lot of relation between columns and cells. That's where polynomial commitment comes to rescue. We write each column as a polynomial. We interpret the column as a polynomial. For example you can say that okay the values in the columns you can see them as the coefficient of a polynomial and by this the constraint would be translated as a relation between polynomials. And from here, you can apply polynomial commitment. I remind you that polynomial commitment can do two tasks for you, which are very simple but very important. One task was it can commit by a short commitment, and you can use the commitment to open to request the evaluation of the polynomial. Another interesting property of the polynomials that why we are interested in polynomial and why we are going from columns to polynomials is thanks to this lemma Schwartz-Dipper lemma, and it says that if you have a relation for a polynomial, between polynomial commitments, you don't need to check the relation for each x, you just take a random point from the domain and if the relation over the random point alpha is satisfied, then you know that it was satisfied for every x. This would simplify everything and that's why we are interested in polynomials. Because by this verifier task is very easy. It just needs to take a random point and then verify the polynomial and constraint over this random point. So by this, we can get now polynomials, a bunch of polynomials and constraints. We are very close to get the proof but we are not still there and the reason is that this constraint are not the constraint that I want. The constraint that we are interested in are global constraints. Why global constraints? Because thanks to this Schwarz-Zippel lemma you can verify them easily. Global constraints are between cells so you don't need to check them between cells, you use a short ZipLM over a global constraint, and you just check in a random point. So we are interested to kind of reduce this constraint. Every constraint that you have, for example, lookup queries, permutation queries, and a lot of queries that may happen during arithmetization, we want to replace them with global connoisseur because from there we can have a simple verification via Schwarz-Zippel lemma. To do this, to get global connoisseur, we need PIOP. But what is PIOP? PIOP stands for polynomial interactive oracle proof. It's the ideal modeling of a protocol between prover and verifier. You have a third party between prover and verifier, this handsome guy that we call Oracle. Oracle is honest and can answer any question. So prover and verifier start their interactions, and they use this Oracle to help them to reduce their constraint to global constraint. And there is a theorem that says that a polynomial commitment in such construction resembles to an oracle, because oracle does not exist. Such guy does not exist, unfortunately. So we have to replace it with something real. And there is a theorem that says that polynomial commitment is a good candidate and you can replace it with this guy to help you to reduce your polynomials to constraint to normal to global and now we are fine so we use P IOP you reduce everything to the global constraint and we can use a polynomial commitment for this. But we cannot use R-Vortex. And the reason is that R-Vortex is not a standard polynomial commitment and the theorem is not true. It's not a good candidate for Oracle. Why it's not a good candidate? It's because of this property, least property. Why it makes problem? Why it cannot work with PIOP? And the reason is that in PIOP you have rounds of interactions between prover and verifier and in fact due to this least property polynomial has a lot of choices in different rounds. And he can do kind of mix-match attack between different rounds and different polynomials from the list. But we have a trick for this. We can prevent, in fact, we use a trick to force, which we call it commit separately and open collectively. And by this, I don't go to the details, theoretical details, but by this trick, we are able to force the prover, in fact, to open all the polynomial commitments at the same position over the disk, let's say. So for the first round, maybe he has choices, but for the other rounds, he doesn't have choice, and he has to stick to the first choice. So this would solve the problem of list, but still, vortex is not good. One more step. And why it's not good? It's now because this noise property, I call it noise because it's batching, but batching, it's not a general batching. As you see in vortex, the batching is just a batching of all the polynomials over the same point. And in the real application, PIOP applications, when you applied your PIOP, in fact, you are in the general case that you have many polynomials, many points. So this kind of batching, even though it's nice, but it's more fantasy and it's not applicable here. But we also find another theoretical trick to solve this problem. Still, I would not go to the theory, just the general view is that we come back to the step that we designed our PIOP, and we kind of modify it to be able to use a batching over the same point and the way that we modify it is just first the convert can speak freely and at the end we apply a kind of reduction via Oracle over the same point and from here now vortex is applicable we can replace our vortex with Oracle and we are done finally we have our first proof and here is just an example of the parameters if you are interested thank you very much. I love the dynamic between the two of you explaining the different sides. It was cool. We have some questions and also some that I had. Sorry, I also introduced you wrong. I said you're from the prover team of ConsenSys. And then I was like, ConsenSys doesn't do proofs. So from the Linnea team, and I guess that became clear immediately. But yeah, so one of the first questions was, is this the vortex that Linnea uses? Yes, this is the first proof. That's why I mentioned that finally we have our first proof. This is the first proof that we generate. After, there are a lot of more layers that will come to aggregate the these initial proofs and finally a final proof to be compatible with aetherium but this is yes this is the first proof that we generate in linear and the classic any benchmarks because as I said this is the first proof. So we have several kind of recursion. And our estimation is that you need, for 100 bits of security, you need 15 millions of constraints for the verifier of vortex inside of Planck. And comparing to Breakdown and Ligero that are in unique decoding, this is four times fast, not faster, but the size of the proof is four times smaller. Nice. So I think this question comes up, well this might answer the next question in part at least. So what are the advantages, disadvantages of Vortex compared to other polynomial commitment schemes? So in terms of prover time, proof size, you mentioned the proof size already. Yes, I mentioned about proof size that is faster than breakdown, smaller than breakdown four times due to the least commitment property. And regarding the prover time, both are good. I mean, it's as good as breakdown, but it's also, I can compare it with fry, for example, because Vortex, it's a very important property that it doesn't need trusted setup. It's like Frye. And comparing to Frye, the prover is faster. Yeah. Good. So, a last question. Is batching over the same point, does it impact the security? That's why we went all through this modifying POP and modifying this trick of commit separately open collectively. All of this was for the proof of security so the paper in fact analyzed the security that, it's not a standard commitment, so how can we use it securely? Nice. I see maybe one more question came in as we have two minutes left for questions. Maybe we can scroll and see. I actually left my phone. Okay. Never mind. What question would you love to hear? Pick your own question. What field do you use? In fact, the only property that we need is because we use FFT, so the only property that we need is to add city, which means that the order of a if your field is a Q the prime that you are using Q minus Y should be a big factor of 2 so if you have this property it's enough for us after because we also have used it's a lattice for the hash, for hashing of the columns. So we may, for optimization, we have more choices in distance. But already this fact that we just need two addicity, it would give us a big choice. Nice. Good. And thank you to whoever uploaded the question so we could read it. Collaboration at its finest. So let's thank the speakers once again. Thank you. And yeah, catch them if you want to know about Linnaeus Provers. Thank you very much. Bye.", "eventId": "devcon-7", "slot_start": 1731409200000, "slot_end": 1731411000000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xTWn8OHn3Uo4DFB83e-yHN6sTgrIz_lfqTY2XGPrx98" + "resources_presentation": "https://docs.google.com/presentation/d/1xTWn8OHn3Uo4DFB83e-yHN6sTgrIz_lfqTY2XGPrx98", + "resources_slides": null, + "speakers": [ + "azam-soleimanian", + "bogdan-ursu" + ] } \ No newline at end of file From 2e6a820bebd0ae681f92c3456bd64dea56ba6381 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 11:21:25 +0700 Subject: [PATCH 15/17] [skip deploy] PUT /sessions/do-you-really-know-your-web3-users --- .../do-you-really-know-your-web3-users.json | 33 ++++++++++++------- 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/do-you-really-know-your-web3-users.json b/devcon-api/data/sessions/devcon-7/do-you-really-know-your-web3-users.json index 7d4f635a..8069127a 100644 --- a/devcon-api/data/sessions/devcon-7/do-you-really-know-your-web3-users.json +++ b/devcon-api/data/sessions/devcon-7/do-you-really-know-your-web3-users.json @@ -9,11 +9,6 @@ "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Product Management", - "Strategy", - "Product Discovery" - ], "tags": [ "Product-market fit", "User Experience", @@ -26,16 +21,30 @@ "User Experience", "User Research" ], - "language": "en", - "speakers": [ - "rahul-rumalla", - "alice-chaverot", - "austin-keeble", - "romina-bungert" + "keywords": [ + "Product Management", + "Strategy", + "Product Discovery" ], + "duration": 3425, + "language": "en", + "sources_swarmHash": "", + "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_presentation": "https://docs.google.com/presentation/d/1NT9-QOOV4dbn06g_FMOVREI8em-zEVjMVNnJ2DBkCuc", + "resources_slides": null, + "speakers": [ + "alice-chaverot", + "austin-keeble", + "rahul-rumalla", + "romina-bungert" + ] } \ No newline at end of file From 2d88856542d23a8ac45a71d49923912bdcf4aaed Mon Sep 17 00:00:00 2001 From: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 04:28:37 +0000 Subject: [PATCH 16/17] [action] Pretalx Sync --- devcon-api/data/events/devcon-7.json | 2 +- ...redefining-daos-state-of-daos-in-asia.json | 4 +- .../devcon-7/white-rabbit-world-premiere.json | 2 +- devcon-api/data/speakers/fudong-wu.json | 1 + devcon-api/data/vectors/devcon-7.json | 51913 +++++++++------- devcon-api/data/vectors/dictionary.json | 8 +- 6 files changed, 27955 insertions(+), 23975 deletions(-) diff --git a/devcon-api/data/events/devcon-7.json b/devcon-api/data/events/devcon-7.json index 3d5925b5..922ac1ba 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": "1731469314581" + "version": "1731471401875" } \ No newline at end of file diff --git a/devcon-api/data/sessions/devcon-7/redefining-daos-state-of-daos-in-asia.json b/devcon-api/data/sessions/devcon-7/redefining-daos-state-of-daos-in-asia.json index 0283ff52..379fa2d2 100644 --- a/devcon-api/data/sessions/devcon-7/redefining-daos-state-of-daos-in-asia.json +++ b/devcon-api/data/sessions/devcon-7/redefining-daos-state-of-daos-in-asia.json @@ -25,10 +25,10 @@ "language": "en", "speakers": [ "joseph-low", + "dev-lewis", "hazel-devjani", "gen", - "yvonne", - "vivian-chen" + "yvonne" ], "eventId": "devcon-7", "slot_start": 1731472200000, diff --git a/devcon-api/data/sessions/devcon-7/white-rabbit-world-premiere.json b/devcon-api/data/sessions/devcon-7/white-rabbit-world-premiere.json index 3af35436..ee7cbaaf 100644 --- a/devcon-api/data/sessions/devcon-7/white-rabbit-world-premiere.json +++ b/devcon-api/data/sessions/devcon-7/white-rabbit-world-premiere.json @@ -7,7 +7,7 @@ "type": "Music", "expertise": "Beginner", "audience": "Design", - "featured": false, + "featured": true, "doNotRecord": false, "keywords": [ "animation", diff --git a/devcon-api/data/speakers/fudong-wu.json b/devcon-api/data/speakers/fudong-wu.json index 986bff0a..052839f4 100644 --- a/devcon-api/data/speakers/fudong-wu.json +++ b/devcon-api/data/speakers/fudong-wu.json @@ -4,5 +4,6 @@ "name": "Fudong Wu", "avatar": "https://speak.devcon.org/media/avatars/a7a24d63-bbe6-4c43-adb8-56295008130e_RAAgCFS.webp", "description": "Fudong Wu is researcher🧑‍🔬. His research interests include blockchain security monitoring and anonymized network communication.", + "github": "1033309821", "hash": "835d9682af9c29196a09363fc1e2363c3ab3f96ba0c97b070796490ec983cc91" } \ No newline at end of file diff --git a/devcon-api/data/vectors/devcon-7.json b/devcon-api/data/vectors/devcon-7.json index 7af19fec..e9acd649 100644 --- a/devcon-api/data/vectors/devcon-7.json +++ b/devcon-api/data/vectors/devcon-7.json @@ -64,6 +64,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -784,6 +785,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 6, 6, @@ -1411,6 +1415,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -2693,6 +2698,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -2772,6 +2780,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -3495,6 +3504,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 6, 6, @@ -4130,6 +4142,7 @@ 0, 0, 0, + 0, 4, 4, 0, @@ -4858,6 +4871,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 6, 6, @@ -5491,6 +5507,7 @@ 0, 0, 0, + 0, 4, 4, 0, @@ -6211,6 +6228,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -6857,6 +6877,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -7589,6 +7610,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -8217,6 +8241,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -8955,6 +8980,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -9575,6 +9603,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -10286,6 +10315,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -10934,6 +10966,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -11677,6 +11710,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -12292,6 +12328,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -13039,6 +13076,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -13650,6 +13690,7 @@ 0, 0, 0, + 0, 4, 0, 0, @@ -14400,6 +14441,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -15010,6 +15054,7 @@ 0, 0, 0, + 0, 4, 4, 0, @@ -15738,6 +15783,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -16376,6 +16424,7 @@ 0, 0, 0, + 0, 4, 4, 4, @@ -17097,6 +17146,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -17737,6 +17789,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -18490,6 +18543,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -19096,6 +19152,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -19848,6 +19905,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -20473,6 +20533,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -21192,6 +21253,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -21832,6 +21896,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -22599,6 +22664,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -23190,6 +23258,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -23923,6 +23992,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -24545,6 +24617,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -25249,6 +25322,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -25898,6 +25974,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -26674,6 +26751,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -28501,6 +28581,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -29845,6 +29929,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -29943,6 +30031,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -30720,6 +30809,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -31302,6 +31394,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -32060,6 +32153,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -32671,6 +32767,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -33376,6 +33473,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 6, 0, @@ -34038,6 +34138,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -34742,6 +34843,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -35398,6 +35502,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -36183,6 +36288,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -36754,6 +36862,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -37539,6 +37648,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 2, @@ -38115,6 +38227,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -38827,6 +38940,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -39469,6 +39585,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -40189,6 +40306,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -40826,6 +40946,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -41606,6 +41727,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -42182,6 +42306,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -42905,6 +43030,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -43542,6 +43670,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -44261,6 +44390,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -44898,6 +45030,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -45611,6 +45744,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -46250,6 +46386,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -47035,6 +47172,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -47613,6 +47753,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -48310,6 +48451,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -48966,6 +49110,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -49662,6 +49807,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -50320,6 +50468,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -51053,6 +51202,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -51681,6 +51833,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -52361,6 +52514,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -53041,6 +53197,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -53736,6 +53893,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -54401,6 +54561,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -55088,6 +55249,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -55666,10 +55830,6 @@ "audience": "Academic", "featured": false, "doNotRecord": false, - "keywords": [ - "Provable", - "Security" - ], "tags": [ "Layer 2s", "Rollups", @@ -55682,16 +55842,29 @@ "Rollups", "Zero-Knowledge" ], - "language": "en", - "speakers": [ - "azam-soleimanian", - "bogdan-ursu" + "keywords": [ + "Provable", + "Security" ], + "duration": 1518, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "V7hmwJ-l0qY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341fe49dbb7a90e16f03c3.vtt", + "transcript_text": " Hi, everyone. So today we're going to talk about how to build provers. This is a joint talk with my colleague, Azam. And yeah, the main purpose of the talk is to see how we can use these polynomial commitments. And we're going to create something based on Ligero and Breakdown, which are two previous works. So just a quick word about us. We're both cryptography researchers at ConsenSys, and we're working in the Linear Prover team. And since you're here, you probably have been hearing all this time how to make proofs, how to make proofs, you want to make proofs, and this talk, this intermediate cryptography talk is about how to actually do that mathematically and how to construct a proof system. So we're going to dig into some details, some mathematical details, but we're going to do that hopefully in a way that carries information across to you. So just some motivation. At the high level, we're interested in how we can move from an EVM state to another one. There is the Ethereum virtual machine state transition that basically explains how that happens. And what happens in the layer two rollups is that this state transition is being arithmetized, and then we compute the proof that the state transition happened properly. And why this is useful is that not all nodes will have to perform the state transition themselves. They can just verify the proof. And since verification will be by design a very cheap operation, the overall system is going to be quite efficient. And as I already prepared you, we're going to look into how to construct such a proof system. There will be two parts in our talk. The first part will be the polynomial commitment scheme, which we call Vortex. And the second part will be how to use this polynomial commitment scheme, some other machinery, in order to reason about the VM execution. So let's dip into cryptography with polynomial commitments So basically like these two parts are the main building blocks of how to build a snark so polynomial commitments first you're going to have just a setup algorithm and At a very high level is just going to give you some public parameters so public parameters and if you want to commit you're going to use these public parameters you're going to use some polynomial you want to commit to a polynomial this polynomial will have some bounded degree K and you're going to output some commitments C and then we want to reason about this polynomial, about this commitment that we just made. And basically, we're going to look at the protocol that's interactive between a prover and a verifier. They both have access to the polynomial, to the parameters, to the commitment. And in the case of the prover also, yeah, also the polynomial, the verifier doesn't know the polynomial, only knows the commitment. And the prover basically attempts to prove that P of X is indeed equal to Y. And this happens over multiple interaction routes. Very high level, the security condition that we want to achieve is that the prover should not be able to convince the verifier in the case that he committed to something, to some polynomial that actually does not evaluate to the claimed Y. And we want to do this efficiently. We want to amortize our costs. So basically we're going to do something called batch polynomial commitments in which instead of committing to only one polynomial, we're going to commit to N of them. We're going to commit to n of them. We're going to claim n evaluations. And basically, the proof is going to be a batch proof, a combined proof, that all of these polynomials evaluate properly. And also, the verifier now knows the evaluation, the claimed evaluations. And let's look into the math that we use in order to build such a thing. These are called the Reed-Solomon codes. And without getting into the nitty gritty, we're going to use a finite field, f. If you don't know what a finite field is, just imagine integers, modulus, and prime p. And we are going to take some subset of n elements a1 to an from this finite field then encoding a polynomial so this is about the codes encoding a polynomial will just be evaluated the polynomial at this endpoints and in order for you to actually in order for this encoding to actually express information about the polynomial you want that the degree of P is actually smaller or equal than N in order to actually be able to express it uniquely. And in fact, you want to have, this N is going to be much higher, you want to have redundant information about the polynomial in order to error correct. And now let's look at the starting point where we took inspiration for our work, which is the Ligero breakdown protocol. These are two separate schemes, but they have a very common structure. So in this previous work, the setup algorithm would give you a hash function as the public parameters. And then in order to commit to n polynomials, what you're going to do is that you're going to first compute the encodings, the Reed-Solomon encodings of the n polynomials. Each row now corresponds to an encoding. You're going to construct this matrix, and you're going to apply a hash function on each column in order to get H1. Then you apply the hash function on the second column to get H2 and so on and this is going to be your commitment your commitment is these hashes of the columns of the encodings of your polynomials so that's how you commit and I put this here in case you forget it. Now we are so interested in how do we open, how do we actually prove to the verifier that our claimed evaluations are correct in a secure way. So basically the verifier is going to send the coin beta to the prover. The prover is going to compute, this looks like a complicated equation, but actually it's not. It's just you have each row, and each row gets multiplied with the power of beta. So it's a linear combination of the rows with this beta that comes from the verifier. This is a vector u. Send it to the verifier. The verifier now picks an index that it wants to check. It's only going to be able to check one. Send it back. And the prover replies to the column of that specific index in this case this is the first one the verifier does two checks it checks that indeed when it applies the hash function to the opened column to the one that we just revealed it is equal to the one in the commitment and it checks that indeed if you compute the linear combination of the betas with the revealed columns then you're going to get the ith coordinate of u. And this protocol is going to ensure that all the rows are indeed codewords. But we want more than this. We want to actually make a proof about the claimed evaluations of the polynomial, not just show that the rows are codewords. And what we notice in this work is that if we interpolate this vector that is sent by the prover to obtain some polynomial, and then we also check that this polynomial evaluated at x is equal to the linear combinations of the y's, if we do this additional check, we can prove that the polynomials evaluate properly and this proof can be very simple if you are in the unique decoding regime which I'm just going to talk about next the point is that if you want to opt it if you want optimal parameters the proof becomes very complicated and I'm going to give you just a flavor of why that is. So basically, when you're talking about codes, you can consider two cases. There is the unique decoding, which in this case is exemplified by this radius. This is the target vector that we want to decode. And this is a radius around it. And as you can see, if you set it this length, then there is only one code word. However, you can also consider relaxing this parameter to be able to include multiple points that are candidates for your decoding. And the proof for our polynomial commitments can become much more complicated if you want the optimal parameters, if you want to have something that's efficient in practice. So as I said, the small one is the unique decoding regime, there's only one candidate and the yellow one is the least one, multiple candidates. So the security guarantee in the that we show in the least decoding regime is that there will exist polynomials of small degree that evaluate correctly and these commitments will have only a small amount of coordinates that are different from the target commitment that we are decoding. And if you want more details for the proof of security, you can check out our ePrint. Thanks a lot. Now we're going to move to the second part of the talk, where we're looking at how can we use this polynomial commitment in conjunction with other things to reason about the EVM and I'm handing over to my colleague Azam. Thank you Bogdan. So let's go to the second part. How and here we are focusing what is happening on layer two, linear, and how we generate proof from EVM execution via such polynomial commitment. There are a lot of steps until we can generate proof. The first step in this journey is arithmetization. And arithmetization for us is mathematical modeling of EVM by columns and constraints between columns. For example, if you want to prove that a transaction had a valid signature, first you hash the signature, so you have to prove that the hash was correct. So if I want to here to show that hash of is why I start with column X and column X is a kind of describing your input X for example you can consider the byte of the X which are splitted in the cells of these columns then which with each steps of the computation that is happening in the hash, this column, you would have a new column with new values in the cell and so on until that you would arrive to column Y, which is your output. And there is constraint between this column to say that how the computation of the hash is going on so by this arithmetization here you get bunch of columns and constraint between columns there are different constraints for example it's just example here there are more lookup constraints or query we also can say which says column R is included in column B or local constraint that says okay if you have two columns then the first row of these two columns are equal global cond constraints, which are very important for us, and they are more about cells, the relation over the cells of the same column or even between several columns. I'm putting an example here for Fibonacci sequence. For this Fibonacci sequence, we know that for each cell is in fact addition of two previous cells. So you write the constraint like this. And we call this one trace, trace of execution or Fibonacci. Okay, if you want to verify this constraint as a verifier, definitely you don't want to do it like this because it's too many efforts, especially global constraints because they are over the cells constraint as a verifier. Definitely you don't want to do it like this because it's too many effort especially global constraint because they are over the cells and you have to check a lot of relation between columns and cells. That's where polynomial commitment comes to rescue. We write each column as a polynomial. We interpret the column as a polynomial. For example you can say that okay the values in the columns you can see them as the coefficient of a polynomial and by this the constraint would be translated as a relation between polynomials. And from here, you can apply polynomial commitment. I remind you that polynomial commitment can do two tasks for you, which are very simple but very important. One task was it can commit by a short commitment, and you can use the commitment to open to request the evaluation of the polynomial. Another interesting property of the polynomials that why we are interested in polynomial and why we are going from columns to polynomials is thanks to this lemma Schwartz-Dipper lemma, and it says that if you have a relation for a polynomial, between polynomial commitments, you don't need to check the relation for each x, you just take a random point from the domain and if the relation over the random point alpha is satisfied, then you know that it was satisfied for every x. This would simplify everything and that's why we are interested in polynomials. Because by this verifier task is very easy. It just needs to take a random point and then verify the polynomial and constraint over this random point. So by this, we can get now polynomials, a bunch of polynomials and constraints. We are very close to get the proof but we are not still there and the reason is that this constraint are not the constraint that I want. The constraint that we are interested in are global constraints. Why global constraints? Because thanks to this Schwarz-Zippel lemma you can verify them easily. Global constraints are between cells so you don't need to check them between cells, you use a short ZipLM over a global constraint, and you just check in a random point. So we are interested to kind of reduce this constraint. Every constraint that you have, for example, lookup queries, permutation queries, and a lot of queries that may happen during arithmetization, we want to replace them with global connoisseur because from there we can have a simple verification via Schwarz-Zippel lemma. To do this, to get global connoisseur, we need PIOP. But what is PIOP? PIOP stands for polynomial interactive oracle proof. It's the ideal modeling of a protocol between prover and verifier. You have a third party between prover and verifier, this handsome guy that we call Oracle. Oracle is honest and can answer any question. So prover and verifier start their interactions, and they use this Oracle to help them to reduce their constraint to global constraint. And there is a theorem that says that a polynomial commitment in such construction resembles to an oracle, because oracle does not exist. Such guy does not exist, unfortunately. So we have to replace it with something real. And there is a theorem that says that polynomial commitment is a good candidate and you can replace it with this guy to help you to reduce your polynomials to constraint to normal to global and now we are fine so we use P IOP you reduce everything to the global constraint and we can use a polynomial commitment for this. But we cannot use R-Vortex. And the reason is that R-Vortex is not a standard polynomial commitment and the theorem is not true. It's not a good candidate for Oracle. Why it's not a good candidate? It's because of this property, least property. Why it makes problem? Why it cannot work with PIOP? And the reason is that in PIOP you have rounds of interactions between prover and verifier and in fact due to this least property polynomial has a lot of choices in different rounds. And he can do kind of mix-match attack between different rounds and different polynomials from the list. But we have a trick for this. We can prevent, in fact, we use a trick to force, which we call it commit separately and open collectively. And by this, I don't go to the details, theoretical details, but by this trick, we are able to force the prover, in fact, to open all the polynomial commitments at the same position over the disk, let's say. So for the first round, maybe he has choices, but for the other rounds, he doesn't have choice, and he has to stick to the first choice. So this would solve the problem of list, but still, vortex is not good. One more step. And why it's not good? It's now because this noise property, I call it noise because it's batching, but batching, it's not a general batching. As you see in vortex, the batching is just a batching of all the polynomials over the same point. And in the real application, PIOP applications, when you applied your PIOP, in fact, you are in the general case that you have many polynomials, many points. So this kind of batching, even though it's nice, but it's more fantasy and it's not applicable here. But we also find another theoretical trick to solve this problem. Still, I would not go to the theory, just the general view is that we come back to the step that we designed our PIOP, and we kind of modify it to be able to use a batching over the same point and the way that we modify it is just first the convert can speak freely and at the end we apply a kind of reduction via Oracle over the same point and from here now vortex is applicable we can replace our vortex with Oracle and we are done finally we have our first proof and here is just an example of the parameters if you are interested thank you very much. I love the dynamic between the two of you explaining the different sides. It was cool. We have some questions and also some that I had. Sorry, I also introduced you wrong. I said you're from the prover team of ConsenSys. And then I was like, ConsenSys doesn't do proofs. So from the Linnea team, and I guess that became clear immediately. But yeah, so one of the first questions was, is this the vortex that Linnea uses? Yes, this is the first proof. That's why I mentioned that finally we have our first proof. This is the first proof that we generate. After, there are a lot of more layers that will come to aggregate the these initial proofs and finally a final proof to be compatible with aetherium but this is yes this is the first proof that we generate in linear and the classic any benchmarks because as I said this is the first proof. So we have several kind of recursion. And our estimation is that you need, for 100 bits of security, you need 15 millions of constraints for the verifier of vortex inside of Planck. And comparing to Breakdown and Ligero that are in unique decoding, this is four times fast, not faster, but the size of the proof is four times smaller. Nice. So I think this question comes up, well this might answer the next question in part at least. So what are the advantages, disadvantages of Vortex compared to other polynomial commitment schemes? So in terms of prover time, proof size, you mentioned the proof size already. Yes, I mentioned about proof size that is faster than breakdown, smaller than breakdown four times due to the least commitment property. And regarding the prover time, both are good. I mean, it's as good as breakdown, but it's also, I can compare it with fry, for example, because Vortex, it's a very important property that it doesn't need trusted setup. It's like Frye. And comparing to Frye, the prover is faster. Yeah. Good. So, a last question. Is batching over the same point, does it impact the security? That's why we went all through this modifying POP and modifying this trick of commit separately open collectively. All of this was for the proof of security so the paper in fact analyzed the security that, it's not a standard commitment, so how can we use it securely? Nice. I see maybe one more question came in as we have two minutes left for questions. Maybe we can scroll and see. I actually left my phone. Okay. Never mind. What question would you love to hear? Pick your own question. What field do you use? In fact, the only property that we need is because we use FFT, so the only property that we need is to add city, which means that the order of a if your field is a Q the prime that you are using Q minus Y should be a big factor of 2 so if you have this property it's enough for us after because we also have used it's a lattice for the hash, for hashing of the columns. So we may, for optimization, we have more choices in distance. But already this fact that we just need two addicity, it would give us a big choice. Nice. Good. And thank you to whoever uploaded the question so we could read it. Collaboration at its finest. So let's thank the speakers once again. Thank you. And yeah, catch them if you want to know about Linnaeus Provers. Thank you very much. Bye.", "eventId": "devcon-7", "slot_start": 1731409200000, "slot_end": 1731411000000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xTWn8OHn3Uo4DFB83e-yHN6sTgrIz_lfqTY2XGPrx98" + "resources_presentation": "https://docs.google.com/presentation/d/1xTWn8OHn3Uo4DFB83e-yHN6sTgrIz_lfqTY2XGPrx98", + "resources_slides": null, + "speakers": [ + "azam-soleimanian", + "bogdan-ursu" + ] }, "vector": [ 0, @@ -55764,6 +55937,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -56433,6 +56607,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -57126,6 +57303,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -57800,6 +57978,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -58480,6 +58661,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -59215,6 +59397,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -59840,6 +60025,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -60617,6 +60803,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -61199,6 +61388,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -61882,6 +62072,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -62552,6 +62745,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -63325,6 +63519,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -63900,6 +64097,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -65124,6 +65322,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -65258,6 +65459,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -65925,6 +66127,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -66623,6 +66828,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -67361,6 +67567,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -67985,6 +68194,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -68720,6 +68930,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -69361,6 +69574,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -70022,6 +70236,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -70717,6 +70934,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -71373,6 +71591,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -72078,6 +72299,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -72736,6 +72958,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -74638,6 +74863,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -74782,6 +75011,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -75453,6 +75683,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -76150,6 +76383,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -76909,6 +77143,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -77522,6 +77759,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -78238,6 +78476,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -78892,6 +79133,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -79541,7 +79783,10 @@ 0, 0, 0, - 6, + 0, + 0, + 0, + 6, 0, 0, 0, @@ -80260,6 +80505,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -80908,6 +81154,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -81619,6 +81868,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -82256,6 +82506,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -82977,6 +83230,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -83633,6 +83887,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -84336,6 +84593,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -84981,6 +85239,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -85695,6 +85956,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -86336,6 +86598,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -86997,6 +87262,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -87771,6 +88037,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -88352,6 +88621,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -89126,6 +89396,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -89702,6 +89975,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -90476,6 +90750,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -91106,6 +91383,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -91837,6 +92115,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -92423,6 +92704,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -93120,6 +93402,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -93830,6 +94115,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -94560,6 +94846,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -95194,6 +95483,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -95844,6 +96134,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -96551,6 +96844,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -97195,6 +97489,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -97912,6 +98209,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -98540,6 +98838,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -99273,6 +99574,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -99946,6 +100248,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -100641,6 +100946,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -101288,6 +101594,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -102001,6 +102310,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -102683,6 +102993,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -103360,6 +103673,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -103975,6 +104289,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -104717,6 +105034,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -105382,6 +105700,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -106014,6 +106335,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -106703,6 +107025,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -107358,6 +107683,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -108063,6 +108389,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -108811,6 +109140,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -109446,6 +109776,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -110171,6 +110504,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -110832,6 +111166,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -111535,6 +111872,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -112237,6 +112575,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -112895,6 +113236,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -113511,6 +113853,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -114247,6 +114592,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -114876,6 +115222,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -115602,6 +115951,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -116221,6 +116571,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -116955,6 +117308,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -117613,6 +117967,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -118314,6 +118671,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -119036,6 +119394,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -119680,6 +120041,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -120303,6 +120665,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -121040,6 +121405,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -121730,6 +122096,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -122396,6 +122765,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -123091,6 +123461,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -123755,6 +124128,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -124347,6 +124721,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -125109,6 +125486,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -125742,6 +126120,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -126466,6 +126847,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -127065,6 +127447,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -127817,6 +128202,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -128412,6 +128798,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -129172,6 +129561,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -129759,6 +130149,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -130528,6 +130921,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -131153,6 +131547,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -131888,6 +132285,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -132468,6 +132866,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -133246,6 +133647,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -133836,6 +134238,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 6, @@ -134606,6 +135011,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -135194,6 +135600,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -135965,6 +136374,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -136556,6 +136966,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -137324,6 +137737,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -137957,6 +138371,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -138683,6 +139100,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -139311,6 +139729,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -139973,6 +140394,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -140654,6 +141076,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -141418,6 +141843,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -142011,6 +142437,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -142779,6 +143208,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -143369,6 +143799,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -144142,6 +144575,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -144738,6 +145172,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 2, 0, @@ -145504,6 +145941,7 @@ 0, 0, 0, + 0, 6, 6, 6, @@ -146090,6 +146528,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -147976,6 +148417,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -148203,6 +148648,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -148784,6 +149230,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -149565,6 +150014,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -150234,6 +150684,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -150924,6 +151377,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -151495,6 +151949,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 6, 0, @@ -152282,6 +152739,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -152941,6 +153399,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -153643,6 +154104,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -154200,6 +154662,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -154996,6 +155461,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -155565,6 +156031,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -156347,36 +156816,40 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 0, + 6, + 6, + 6, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -157486,25 +157959,31 @@ }, { "session": { - "id": "cls-eth-escape-speed-hacking-challenge", - "sourceId": "RSYU7K", - "title": "[CLS] ETH Escape - Speed Hacking Challenge", - "description": "​Prize Pool: $50,000\r\n\r\n​A High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", + "id": "cls-ethereum-magicians-infinite-endgames-block-construction", + "sourceId": "3AWFTE", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Block construction", + "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum’s roadmap. Join us here to discuss the “infinite endgame” for block construction. We'll cover PBS, MEV, role of validators vs. builders, centralization risks, and more!\r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", + "track": "[CLS] Infinite Endgames by Ethereum Magicians", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [], + "tags": [ + "Blobs", + "MEV", + "PBS" + ], "language": "en", - "speakers": [], + "speakers": [ + "alex-stokes" + ], "eventId": "devcon-7", - "slot_start": 1731551400000, - "slot_end": 1731573000000, + "slot_start": 1731650400000, + "slot_end": 1731655800000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0" + "resources_presentation": "https://docs.google.com/presentation/d/1yeTJ8P67T5QYFuo5u1uIU8PtyMBoM_1mpCtwWM27BQc" }, "vector": [ 0, @@ -157516,8 +157995,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -157526,6 +158003,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -157698,6 +158176,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -158252,6 +158731,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -158288,6 +158768,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -158312,6 +158793,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -158812,13 +159294,14 @@ 2, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -158830,31 +159313,34 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-block-construction", - "sourceId": "3AWFTE", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Block construction", - "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum’s roadmap. Join us here to discuss the “infinite endgame” for block construction. We'll cover PBS, MEV, role of validators vs. builders, centralization risks, and more!\r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", + "id": "cls-ethereum-magicians-infinite-endgames-ethconomics", + "sourceId": "UFX3NX", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethconomics", + "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum's roadmap. Join us here to discuss the \"infinite endgame\" for Ethereum's economic model. We'll cover the role of Ether in the network's security, issuance proposals, out-of-protocol economic influences, and more! \r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, + "expertise": "Beginner", + "audience": "Engineering", + "featured": true, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Ethconomics", + "Issuance" + ], "tags": [ - "Blobs", + "Economics", "MEV", - "PBS" + "Staking" ], "language": "en", "speakers": [ - "alex-stokes" + "tim-beiko" ], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731655800000, + "slot_start": 1731655800000, + "slot_end": 1731661200000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yeTJ8P67T5QYFuo5u1uIU8PtyMBoM_1mpCtwWM27BQc" + "resources_presentation": "https://docs.google.com/presentation/d/1yfoTOM-8vuH0ZUXAvbG6H3K4-yhQUtdboeWI5L5uJ7M" }, "vector": [ 0, @@ -159046,6 +159532,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -159598,6 +160086,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -159631,11 +160121,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -159660,7 +160150,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -159726,6 +160215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -160158,16 +160648,16 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -160180,34 +160670,31 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ethconomics", - "sourceId": "UFX3NX", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethconomics", - "description": "Once again, Devcon will host Ethereum Magicians gatherings for the community to come together and discuss the most important topics in Ethereum's roadmap. Join us here to discuss the \"infinite endgame\" for Ethereum's economic model. We'll cover the role of Ether in the network's security, issuance proposals, out-of-protocol economic influences, and more! \r\n\r\nFor more context, see: https://bit.ly/ethmag-sea", + "id": "cls-ethereum-magicians-infinite-endgames-ethereum-execution", + "sourceId": "S8NCDC", + "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethereum Execution", + "description": "A fishbowl-style discussion with core Ethereum contributors and community to publicly discuss the \"endgame\" of execution on Ethereum. We will discuss what the evolution of Ethereum’s execution layer will look like, L1 vs. L2, settlement vs. execution, enshrined rollups, consensus changes vs. client performance improvements, etc.", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", - "featured": true, + "expertise": "Expert", + "audience": "Research", + "featured": false, "doNotRecord": false, - "keywords": [ - "Ethconomics", - "Issuance" - ], + "keywords": [], "tags": [ - "Economics", - "MEV", - "Staking" + "Core Protocol", + "In-protocol Account Abstraction", + "Rollups" ], "language": "en", "speakers": [ - "tim-beiko" + "lightclient" ], "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731661200000, + "slot_start": 1731645000000, + "slot_end": 1731650400000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yfoTOM-8vuH0ZUXAvbG6H3K4-yhQUtdboeWI5L5uJ7M" + "resources_presentation": "https://docs.google.com/presentation/d/1Ovum9wCpn-eOO_GaydQ7myGTVXFB4g6lDX0Btv4ApMI" }, "vector": [ 0, @@ -160379,6 +160866,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -160400,7 +160889,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -160951,7 +161439,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -160972,6 +161459,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -160984,7 +161472,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -160995,6 +161482,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -161078,7 +161566,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -161174,6 +161661,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -161513,10 +162004,10 @@ 0, 0, 0, - 2, 0, 2, 0, + 2, 0, 0, 0, @@ -161533,31 +162024,33 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ethereum-execution", - "sourceId": "S8NCDC", - "title": "[CLS] Ethereum Magicians Infinite Endgames: Ethereum Execution", - "description": "A fishbowl-style discussion with core Ethereum contributors and community to publicly discuss the \"endgame\" of execution on Ethereum. We will discuss what the evolution of Ethereum’s execution layer will look like, L1 vs. L2, settlement vs. execution, enshrined rollups, consensus changes vs. client performance improvements, etc.", + "id": "cls-ethereum-magicians-infinite-endgames-ux", + "sourceId": "QRG8QW", + "title": "[CLS] Ethereum Magicians Infinite Endgames: UX", + "description": "UX has been at the forefront of Ethereum recently, as standards for Account and Chain Abstraction have been gaining significant traction in the space.\r\n\r\nJoin us (literally! This panel will be “fishbowl style”) as we discuss the challenges that we will need to figure out first, such as cross-L2 key management, asset handling and transactions; avoiding fragmentation (liquidity, network, users); coordinating standards across L2s and wallets; and more", "track": "[CLS] Infinite Endgames by Ethereum Magicians", "type": "Workshop", - "expertise": "Expert", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "ERC-4337" + ], "tags": [ - "Core Protocol", - "In-protocol Account Abstraction", - "Rollups" + "Account Abstraction", + "Cross-L2", + "UI/UX" ], "language": "en", "speakers": [ - "lightclient" + "tom-teman" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731650400000, + "slot_start": 1731639600000, + "slot_end": 1731645000000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Ovum9wCpn-eOO_GaydQ7myGTVXFB4g6lDX0Btv4ApMI" + "resources_presentation": "https://docs.google.com/presentation/d/1O8Er1O0dSSedqAxQY9z1pjTRU-Hr46AyiOlBS6Dnvq0" }, "vector": [ 0, @@ -161728,7 +162221,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -161753,6 +162245,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -162318,7 +162811,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162341,7 +162833,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162356,6 +162847,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162363,6 +162855,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162505,6 +162998,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -162520,7 +163014,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -162864,7 +163357,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -162874,6 +163366,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -162883,33 +163380,28 @@ }, { "session": { - "id": "cls-ethereum-magicians-infinite-endgames-ux", - "sourceId": "QRG8QW", - "title": "[CLS] Ethereum Magicians Infinite Endgames: UX", - "description": "UX has been at the forefront of Ethereum recently, as standards for Account and Chain Abstraction have been gaining significant traction in the space.\r\n\r\nJoin us (literally! This panel will be “fishbowl style”) as we discuss the challenges that we will need to figure out first, such as cross-L2 key management, asset handling and transactions; avoiding fragmentation (liquidity, network, users); coordinating standards across L2s and wallets; and more", - "track": "[CLS] Infinite Endgames by Ethereum Magicians", - "type": "Workshop", + "id": "cls-formal-verification-hangout", + "sourceId": "ZTHE3N", + "title": "[CLS] Formal Verification Hangout", + "description": "A low key, informal, self-organized event hosted within the Devcon venue* to explore interesting topics in Formal Verification.\r\n\r\nThe event will be casual, with minimal talks/programming, and geared towards facilitating discussions and allowing researchers to connect with others in the field.\r\n\r\n​Agenda\r\n\r\n​2:00 - 2:15 – Welcome\r\n2:15 - 3:30 – Fishbowl Panel\r\n3:30 - 4:00 – Break\r\n4:00 - 5:00 – Lightning Talks**\r\n5:00 - 6:00 – Discussion Groups\r\n6:00 onwards – Informal Discussions", + "track": "[CLS] Formal Verification Hangout, FV Team", + "type": "Mixed Formats", "expertise": "Intermediate", - "audience": "Product", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ERC-4337" - ], + "keywords": [], "tags": [ - "Account Abstraction", - "Cross-L2", - "UI/UX" + "Formal", + "Verification" ], "language": "en", - "speakers": [ - "tom-teman" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731645000000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1O8Er1O0dSSedqAxQY9z1pjTRU-Hr46AyiOlBS6Dnvq0" + "slot_start": 1731394800000, + "slot_end": 1731409200000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1KG701RsIoq1QyT_uxs6WdIDJVZLJz0WL2Zcdl1b-gzg" }, "vector": [ 0, @@ -162929,17 +163421,8 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, + 6, 0, 0, 0, @@ -163103,7 +163586,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -163702,7 +164184,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -163710,7 +164191,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -163853,7 +164333,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -163890,6 +164369,14 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -164213,7 +164700,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -164221,6 +164707,12 @@ 0, 0, 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -164230,33 +164722,40 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "cls-formal-verification-hangout", - "sourceId": "ZTHE3N", - "title": "[CLS] Formal Verification Hangout", - "description": "A low key, informal, self-organized event hosted within the Devcon venue* to explore interesting topics in Formal Verification.\r\n\r\nThe event will be casual, with minimal talks/programming, and geared towards facilitating discussions and allowing researchers to connect with others in the field.\r\n\r\n​Agenda\r\n\r\n​2:00 - 2:15 – Welcome\r\n2:15 - 3:30 – Fishbowl Panel\r\n3:30 - 4:00 – Break\r\n4:00 - 5:00 – Lightning Talks**\r\n5:00 - 6:00 – Discussion Groups\r\n6:00 onwards – Informal Discussions", - "track": "[CLS] Formal Verification Hangout, FV Team", + "id": "cls-programmable-cryptography", + "sourceId": "UTCRP8", + "title": "[CLS] Programmable Cryptography", + "description": "The Programmable Cryptography CLS hosts a series of talks exploring how advanced cryptography can reshape digital infrastructure beyond blockchain and trust infrastructure.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", "type": "Mixed Formats", - "expertise": "Intermediate", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "Formal", - "Verification" - ], + "tags": [], "language": "en", - "speakers": [], + "speakers": [ + "justin-glibert", + "gubsheep", + "barry", + "albert-ni", + "vitalik-buterin" + ], "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731409200000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1KG701RsIoq1QyT_uxs6WdIDJVZLJz0WL2Zcdl1b-gzg" + "slot_start": 1731639600000, + "slot_end": 1731646800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1KpnGjqycfpLNFKUjuTryELdVgZfiVhV0qOcH-f6orS0" }, "vector": [ 0, @@ -164273,11 +164772,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -164445,9 +164945,15 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -165220,8 +165726,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -165563,7 +166067,6 @@ 2, 0, 0, - 0, 2, 0, 0, @@ -165582,31 +166085,45 @@ }, { "session": { - "id": "cls-programmable-cryptography", - "sourceId": "UTCRP8", - "title": "[CLS] Programmable Cryptography", - "description": "The Programmable Cryptography CLS hosts a series of talks exploring how advanced cryptography can reshape digital infrastructure beyond blockchain and trust infrastructure.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", - "featured": false, + "id": "common-knowledge-machines", + "sourceId": "XJPE8K", + "title": "Common Knowledge Machines", + "description": "Common knowledge is a precondition for collective action. Yet, increasing polarization in information ecosystems risks undermining common knowledge formation. This talk introduces Community Posts, a mechanism that leverages diversification and zero-knowledge proofs to help people identify divides, bridge them and find common ground, fostering greater common knowledge in social networks.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": true, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "justin-glibert", - "gubsheep", - "barry", - "albert-ni", - "vitalik-buterin" + "tags": [ + "Censorship Resistance", + "Collective Intelligence", + "Consensus Mechanisms", + "Coordination", + "Identity" ], + "keywords": [ + "Stellar", + "Punk" + ], + "duration": 468, + "language": "en", + "sources_swarmHash": "2fadd824928c32a979645300678ee71dea6d46f238ba5f1acf48e3791e8e8005", + "sources_youtubeId": "B1oh1WrU-7g", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731646800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1KpnGjqycfpLNFKUjuTryELdVgZfiVhV0qOcH-f6orS0" + "slot_start": 1731409200000, + "slot_end": 1731409800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1a63MEhn5HWzDRARwTVIqwlXGcTuEurRAij2MM5-ACMI", + "resources_slides": null, + "speakers": [ + "puja-ohlhaver" + ] }, "vector": [ 0, @@ -165620,10 +166137,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -165795,21 +166312,17 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -166390,6 +166903,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -166404,6 +166918,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -166502,12 +167017,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -166548,6 +167065,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -166911,7 +167429,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -166919,6 +167436,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -166932,47 +167453,38 @@ }, { "session": { - "id": "common-knowledge-machines", - "sourceId": "XJPE8K", - "title": "Common Knowledge Machines", - "description": "Common knowledge is a precondition for collective action. Yet, increasing polarization in information ecosystems risks undermining common knowledge formation. This talk introduces Community Posts, a mechanism that leverages diversification and zero-knowledge proofs to help people identify divides, bridge them and find common ground, fostering greater common knowledge in social networks.", - "track": "Coordination", + "id": "community-notes", + "sourceId": "8F3HQM", + "title": "Community Notes", + "description": "Community Notes allows regular X users to collaboratively add context to potentially misleading posts. It uses a transparent and verifiable mechanism that aims to be credibly neutral by only showing posts liked by users who typically disagree.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", - "featured": true, + "audience": "Engineering", + "featured": false, "doNotRecord": false, + "keywords": [ + "d/acc" + ], "tags": [ "Censorship Resistance", "Collective Intelligence", - "Consensus Mechanisms", - "Coordination", - "Identity" - ], - "keywords": [ - "Stellar", - "Punk" + "Consensus Mechanisms" ], - "duration": 468, "language": "en", - "sources_swarmHash": "2fadd824928c32a979645300678ee71dea6d46f238ba5f1acf48e3791e8e8005", - "sources_youtubeId": "B1oh1WrU-7g", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731409800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1a63MEhn5HWzDRARwTVIqwlXGcTuEurRAij2MM5-ACMI", - "resources_slides": null, "speakers": [ - "puja-ohlhaver" - ] + "jay-baxter" + ], + "eventId": "devcon-7", + "slot_start": 1731561600000, + "slot_end": 1731562200000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/10k5sMswiuZ6sjCWh6_3DzYLI8Ix836tP-o0-fhgeUCI" }, "vector": [ + 0, + 6, + 0, 0, 0, 0, @@ -166984,7 +167496,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -167746,6 +168257,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -167761,7 +168274,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -167867,7 +168380,7 @@ 0, 0, 0, - 2, + 0, 0, 0, 0, @@ -168278,7 +168791,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -168291,57 +168803,48 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "community-notes", - "sourceId": "8F3HQM", - "title": "Community Notes", - "description": "Community Notes allows regular X users to collaboratively add context to potentially misleading posts. It uses a transparent and verifiable mechanism that aims to be credibly neutral by only showing posts liked by users who typically disagree.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "comparing-slashing-penalties-on-proof-of-stake-networks", + "sourceId": "YJZT3K", + "title": "Comparing Slashing Penalties on Proof-of-Stake Networks", + "description": "With the support of the Ethereum Foundation, we have performed an analysis of slashing penalties on the seventy largest proof-of-stake cryptocurrency networks. Using insights from institutional economics and game theory, we consider variance in slashing penalties in terms of the conditions that trigger slashing, the magnitude of penalties contemplated, and the limited cases where human judgment plays a role in determining such penalties.", + "track": "Cryptoeconomics", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc" + "Slashing" ], "tags": [ - "Censorship Resistance", - "Collective Intelligence", - "Consensus Mechanisms" + "Governance", + "Game Theory", + "Economics", + "slashing", + "Economics", + "Game Theory", + "Governance" ], "language": "en", "speakers": [ - "jay-baxter" + "eric-alston" ], "eventId": "devcon-7", - "slot_start": 1731561600000, - "slot_end": 1731562200000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/10k5sMswiuZ6sjCWh6_3DzYLI8Ix836tP-o0-fhgeUCI" + "slot_start": 1731496800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1U1W0kONT5CqQY5olh7ieFlQWhiN9s7HXZjQqM1AuBzg" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -168521,7 +169024,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -168538,6 +169040,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -169090,6 +169593,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -169098,7 +169602,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169117,6 +169620,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -169177,6 +169681,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -169212,7 +169717,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169260,7 +169764,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169306,6 +169809,21 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -169626,7 +170144,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -169635,6 +170152,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -169648,37 +170169,39 @@ }, { "session": { - "id": "comparing-slashing-penalties-on-proof-of-stake-networks", - "sourceId": "YJZT3K", - "title": "Comparing Slashing Penalties on Proof-of-Stake Networks", - "description": "With the support of the Ethereum Foundation, we have performed an analysis of slashing penalties on the seventy largest proof-of-stake cryptocurrency networks. Using insights from institutional economics and game theory, we consider variance in slashing penalties in terms of the conditions that trigger slashing, the magnitude of penalties contemplated, and the limited cases where human judgment plays a role in determining such penalties.", + "id": "conditional-recall", + "sourceId": "XTQUDR", + "title": "Conditional Recall", + "description": "In the neon-lit nights of 2025, Johnson & Johnson unveiled X. A pill, not larger than a snowflake, but it promised a tempest of change. This miraculous drug didn't just allow people to cherry-pick memories to erase from their minds, it also can credibly leave a reminder in people's minds that those memories has been vanished, forever.\r\nWe explore the game theoretic implications of a technology (such as TEEs) that allows players to commit to forget information and discuss several applications.", "track": "Cryptoeconomics", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Slashing" + "TEE", + "Commitment" ], "tags": [ - "Governance", + "Mechanism design", "Game Theory", "Economics", - "slashing", + "commitment", "Economics", "Game Theory", - "Governance" + "Mechanism design" ], "language": "en", "speakers": [ - "eric-alston" + "sxysun", + "christoph-schlegel" ], "eventId": "devcon-7", - "slot_start": 1731496800000, - "slot_end": 1731497400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1U1W0kONT5CqQY5olh7ieFlQWhiN9s7HXZjQqM1AuBzg" + "slot_start": 1731648600000, + "slot_end": 1731650400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1jXv2kbSefJjmF8zhC0ibw1x1paaVWwuDjrd37N_Nzj8" }, "vector": [ 0, @@ -169878,6 +170401,9 @@ 0, 0, 0, + 0, + 0, + 6, 6, 0, 0, @@ -170429,6 +170955,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -170516,7 +171043,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -170644,9 +171170,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -171004,44 +171531,46 @@ }, { "session": { - "id": "conditional-recall", - "sourceId": "XTQUDR", - "title": "Conditional Recall", - "description": "In the neon-lit nights of 2025, Johnson & Johnson unveiled X. A pill, not larger than a snowflake, but it promised a tempest of change. This miraculous drug didn't just allow people to cherry-pick memories to erase from their minds, it also can credibly leave a reminder in people's minds that those memories has been vanished, forever.\r\nWe explore the game theoretic implications of a technology (such as TEEs) that allows players to commit to forget information and discuss several applications.", - "track": "Cryptoeconomics", - "type": "Talk", + "id": "coordinating-intelligence-open-algorithm-development-for-science-ai-and-beyond", + "sourceId": "FZRMPJ", + "title": "Coordinating Intelligence : Open Algorithm Development for Science, AI, and Beyond", + "description": "The Innovation Game (TIG) is a market-based framework accelerating development of computational methods crucial to science, engineering, and AI. It creates a \"synthetic market\" where \"Innovators\" contribute methods and are rewarded based on adoption by \"Benchmarkers,\" who are rewarded for solving random instances of computational challenges. This enables price discovery for commercial and pre-commercial research, attracting private investment. TIG's hybrid licensing model ensures open collaborat", + "track": "Coordination", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "TEE", - "Commitment" + "Innovation", + "Algorithms", + "Optimised Proof of Work" ], "tags": [ - "Mechanism design", - "Game Theory", - "Economics", - "commitment", + "Coordination", + "DeSci", "Economics", - "Game Theory", - "Mechanism design" + "proof", + "optimised", + "work", + "Coordination", + "DeSci", + "Economics" ], "language": "en", "speakers": [ - "sxysun", - "christoph-schlegel" + "dr-john-fletcher-phd", + "kilian-hikaru-scheutwinkel" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731650400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1jXv2kbSefJjmF8zhC0ibw1x1paaVWwuDjrd37N_Nzj8" + "slot_start": 1731566400000, + "slot_end": 1731567000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1LhUMD8kPbukRuIeQXcyC9Nzn52Zdr6JH80byPktkErk" }, "vector": [ 0, 0, - 6, 0, 0, 0, @@ -171051,6 +171580,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -171785,9 +172318,6 @@ 0, 0, 0, - 6, - 6, - 0, 0, 0, 0, @@ -171813,11 +172343,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -171916,6 +172446,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -171936,6 +172467,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -172003,10 +172535,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -172344,7 +172878,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -172357,47 +172890,40 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "coordinating-intelligence-open-algorithm-development-for-science-ai-and-beyond", - "sourceId": "FZRMPJ", - "title": "Coordinating Intelligence : Open Algorithm Development for Science, AI, and Beyond", - "description": "The Innovation Game (TIG) is a market-based framework accelerating development of computational methods crucial to science, engineering, and AI. It creates a \"synthetic market\" where \"Innovators\" contribute methods and are rewarded based on adoption by \"Benchmarkers,\" who are rewarded for solving random instances of computational challenges. This enables price discovery for commercial and pre-commercial research, attracting private investment. TIG's hybrid licensing model ensures open collaborat", + "id": "coordination-accelerationism-a-manifesto", + "sourceId": "NGXHAA", + "title": "Coordination Accelerationism: A Manifesto", + "description": "In this talk, we place crypto in the context of evolutionary timescale. We present an overview of the various types of coordination systems, their advantages and weaknesses. The most robust type of coordination mechanism is something we term as, self-enforcing coordination systems (SECS) - which do not require an authority, a committee or even a majority of entities to enforce the conditions of coordination. We also show how to build the most general form of SECS.", "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", + "type": "Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Innovation", - "Algorithms", - "Optimised Proof of Work" + "Forking" ], "tags": [ - "Coordination", - "DeSci", - "Economics", - "proof", - "optimised", - "work", - "Coordination", - "DeSci", - "Economics" + "fork", + "Collective Intelligence", + "Consensus", + "Coordination" ], "language": "en", "speakers": [ - "dr-john-fletcher-phd", - "kilian-hikaru-scheutwinkel" + "sreeram-kannan" ], "eventId": "devcon-7", - "slot_start": 1731566400000, - "slot_end": 1731567000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1LhUMD8kPbukRuIeQXcyC9Nzn52Zdr6JH80byPktkErk" + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A" }, "vector": [ 0, @@ -172600,7 +173126,9 @@ 0, 0, 0, - 6, + 0, + 0, + 0, 6, 0, 0, @@ -173146,6 +173674,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -173273,7 +173802,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -173365,12 +173895,10 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -173701,10 +174229,12 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 2, + 0, 2, 0, 0, @@ -173723,43 +174253,41 @@ }, { "session": { - "id": "coordination-accelerationism-a-manifesto", - "sourceId": "NGXHAA", - "title": "Coordination Accelerationism: A Manifesto", - "description": "In this talk, we place crypto in the context of evolutionary timescale. We present an overview of the various types of coordination systems, their advantages and weaknesses. The most robust type of coordination mechanism is something we term as, self-enforcing coordination systems (SECS) - which do not require an authority, a committee or even a majority of entities to enforce the conditions of coordination. We also show how to build the most general form of SECS.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", + "id": "copying-memory-in-evm-how-hard-can-that-be", + "sourceId": "JKFBN3", + "title": "Copying Memory in EVM, how hard can that be?", + "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "Forking" + "Optimisations", + "Compilers" ], "tags": [ - "fork", - "Collective Intelligence", - "Consensus", - "Coordination" + "Core Protocol", + "Gas", + "Developer Infrastructure", + "compilers", + "optimised", + "Core Protocol", + "Developer Infrastructure", + "Gas" ], "language": "en", "speakers": [ - "sreeram-kannan" + "elia-anzuoni" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A" + "slot_start": 1731471600000, + "slot_end": 1731472200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -173955,10 +174483,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -173968,6 +174492,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -174497,7 +175022,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -174561,6 +175085,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -174647,31 +175172,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, @@ -174721,7 +175221,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -174759,6 +175258,43 @@ 0, 0, 0, + 2, + 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, @@ -175056,7 +175592,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -175071,50 +175606,51 @@ 0, 0, 0, + 0, + 2, + 0, + 0, 0 ] }, { "session": { - "id": "copying-memory-in-evm-how-hard-can-that-be", - "sourceId": "JKFBN3", - "title": "Copying Memory in EVM, how hard can that be?", - "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "", + "id": "corruption-kyc-and-the-cost-of-compliance", + "sourceId": "8FQ3HT", + "title": "Corruption, KYC and the Cost of Compliance", + "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Optimisations", - "Compilers" + "Compliance", + "Illicit Financial Flows", + "KYC/AML" ], "tags": [ - "Core Protocol", - "Gas", - "Developer Infrastructure", - "compilers", - "optimised", - "Core Protocol", - "Developer Infrastructure", - "Gas" + "Anonymity", + "Censorship Resistance", + "Civil Resistance" ], "language": "en", "speakers": [ - "elia-anzuoni" + "jarrad-hope" ], "eventId": "devcon-7", - "slot_start": 1731471600000, - "slot_end": 1731472200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU" }, "vector": [ 0, 0, 0, 0, + 0, 6, 0, 0, @@ -175314,6 +175850,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -175869,7 +176406,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -175879,6 +176415,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -175904,7 +176441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -176001,6 +176537,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -176077,16 +176614,16 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -176412,11 +176949,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 2, + 0, 0, 0, 0, @@ -176426,7 +176966,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -176434,35 +176973,41 @@ }, { "session": { - "id": "corruption-kyc-and-the-cost-of-compliance", - "sourceId": "8FQ3HT", - "title": "Corruption, KYC and the Cost of Compliance", - "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the", - "track": "Cypherpunk & Privacy", + "id": "cross-l2-with-intent-addresses", + "sourceId": "BEWE3Q", + "title": "Cross L2 with Intent Addresses", + "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.", + "track": "Usability", "type": "Talk", - "expertise": "Beginner", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Compliance", - "Illicit Financial Flows", - "KYC/AML" + "CCTP", + "bridging", + "chain-abstraction" ], "tags": [ - "Anonymity", - "Censorship Resistance", - "Civil Resistance" + "Architecture", + "Cross-L2", + "Account Abstraction", + "chain", + "abstraction", + "Account Abstraction", + "Architecture", + "Cross-L2" ], "language": "en", "speakers": [ - "jarrad-hope" + "nalin-b", + "dc-posch" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU" }, "vector": [ 0, @@ -176470,10 +177015,11 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -176610,6 +177156,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -177230,7 +177777,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -177258,6 +177804,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -177268,6 +177815,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -177352,7 +177900,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -177408,6 +177955,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -177436,7 +177986,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -177766,9 +178315,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 2, 0, @@ -177788,50 +178337,37 @@ }, { "session": { - "id": "cross-l2-with-intent-addresses", - "sourceId": "BEWE3Q", - "title": "Cross L2 with Intent Addresses", - "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "crypto-in-action-powering-ukraines-resilience", + "sourceId": "7JZGQJ", + "title": "Crypto in Action: Powering Ukraine's Resilience", + "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "CCTP", - "bridging", - "chain-abstraction" + "Resilient infrastructure", + "Ukraine", + "crypto donations" ], "tags": [ - "Architecture", - "Cross-L2", - "Account Abstraction", - "chain", - "abstraction", - "Account Abstraction", - "Architecture", - "Cross-L2" + "Civil Resistance", + "Coordination", + "Public good" ], "language": "en", "speakers": [ - "nalin-b", - "dc-posch" + "rev-miller" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU" + "slot_start": 1731581400000, + "slot_end": 1731582000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 6, 0, @@ -177970,40 +178506,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -178030,8 +178532,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -178075,6 +178575,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -178615,7 +179116,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -178626,7 +179126,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -178721,6 +179220,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -178767,16 +179267,6 @@ 0, 0, 2, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -178853,6 +179343,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -179126,62 +179617,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "crypto-in-action-powering-ukraines-resilience", - "sourceId": "7JZGQJ", - "title": "Crypto in Action: Powering Ukraine's Resilience", - "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Resilient infrastructure", - "Ukraine", - "crypto donations" - ], - "tags": [ - "Civil Resistance", - "Coordination", - "Public good" - ], - "language": "en", - "speakers": [ - "rev-miller" - ], - "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao" - }, - "vector": [ - 0, - 6, - 0, 0, 0, 0, @@ -179237,12 +179675,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -179250,12 +179690,62 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy", + "sourceId": "UCZ83J", + "title": "Crypto is the Real World: Understanding the Cryptonative Economy", + "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "tags": [ + "Digital Sovereignty", + "Use Cases", + "Economics", + "cryptonative", + "Digital Sovereignty", + "Economics", + "Use Cases" + ], + "keywords": [ + "Real world", + "Ecosystem", + "Cryptonativism" + ], + "duration": 991, + "language": "en", + "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c", + "sources_youtubeId": "Y0u6J1OmPXc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt", + "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.", + "eventId": "devcon-7", + "slot_start": 1731389400000, + "slot_end": 1731390600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s", + "resources_slides": null, + "speakers": [ + "josef-je" + ] + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -179385,7 +179875,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -179458,6 +179947,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -180042,37 +180532,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, 2, 0, 0, @@ -180102,6 +180561,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -180150,7 +180610,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -180256,6 +180715,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -180482,14 +180942,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -180497,67 +180955,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy", - "sourceId": "UCZ83J", - "title": "Crypto is the Real World: Understanding the Cryptonative Economy", - "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "tags": [ - "Digital Sovereignty", - "Use Cases", - "Economics", - "cryptonative", - "Digital Sovereignty", - "Economics", - "Use Cases" - ], - "keywords": [ - "Real world", - "Ecosystem", - "Cryptonativism" - ], - "duration": 991, - "language": "en", - "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c", - "sources_youtubeId": "Y0u6J1OmPXc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt", - "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731390600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s", - "resources_slides": null, - "speakers": [ - "josef-je" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -180641,6 +181044,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -180648,6 +181052,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -180656,6 +181061,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work", + "sourceId": "YNBTQR", + "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work", + "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Protocol Design", + "Layer 2s", + "Rollups", + "explainer", + "Layer 2s", + "Protocol Design", + "Rollups" + ], + "keywords": [ + "Explainer" + ], + "duration": 1311, + "language": "en", + "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d", + "sources_youtubeId": "c1IbglrscSU", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt", + "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.", + "eventId": "devcon-7", + "slot_start": 1731398400000, + "slot_end": 1731400200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg", + "resources_slides": null, + "speakers": [ + "kelvin-fichter" + ] + }, + "vector": [ 0, 0, 0, @@ -180663,6 +181115,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -180753,7 +181206,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -180865,6 +181317,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -181320,7 +181773,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -181335,7 +181787,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -181364,7 +181815,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -181443,9 +181893,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -181465,6 +181917,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -181518,13 +181971,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -181639,6 +182085,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -181847,80 +182294,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work", - "sourceId": "YNBTQR", - "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work", - "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Protocol Design", - "Layer 2s", - "Rollups", - "explainer", - "Layer 2s", - "Protocol Design", - "Rollups" - ], - "keywords": [ - "Explainer" - ], - "duration": 1311, - "language": "en", - "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d", - "sources_youtubeId": "c1IbglrscSU", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt", - "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731400200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg", - "resources_slides": null, - "speakers": [ - "kelvin-fichter" - ] - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, 0, 0, 0, @@ -182042,7 +182415,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -182055,6 +182430,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond", + "sourceId": "PQBKHF", + "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond", + "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Parallel", + "EVM" + ], + "tags": [ + "Scalability", + "Security", + "Fuzzing", + "EVM", + "parallel", + "Fuzzing", + "Scalability", + "Security" + ], + "language": "en", + "speakers": [ + "minh-ho" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE" + }, + "vector": [ + 6, 0, 0, 0, @@ -182119,7 +182535,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -182265,6 +182680,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -182692,11 +183108,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -182716,10 +183130,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -182803,6 +183213,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -182884,7 +183296,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -182942,6 +183353,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -183010,6 +183422,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -183035,6 +183448,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -183214,9 +183628,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -183229,47 +183641,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond", - "sourceId": "PQBKHF", - "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond", - "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Parallel", - "EVM" - ], - "tags": [ - "Scalability", - "Security", - "Fuzzing", - "EVM", - "parallel", - "Fuzzing", - "Scalability", - "Security" - ], - "language": "en", - "speakers": [ - "minh-ho" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE" - }, - "vector": [ - 6, 0, 0, 0, @@ -183404,10 +183775,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -183419,11 +183792,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve", + "sourceId": "MZMQXY", + "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve", + "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya", + "track": "Cypherpunk & Privacy", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "culture" + ], + "tags": [], + "language": "en", + "speakers": [ + "simona-pop", + "aya-miyaguchi" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731562200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -183478,7 +183883,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -183605,6 +184009,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -183629,6 +184034,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -184008,8 +184414,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -184148,7 +184552,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -184217,7 +184620,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -184243,7 +184645,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -184570,12 +184971,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -184587,43 +184986,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve", - "sourceId": "MZMQXY", - "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve", - "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya", - "track": "Cypherpunk & Privacy", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "culture" - ], - "tags": [], - "language": "en", - "speakers": [ - "simona-pop", - "aya-miyaguchi" - ], - "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731562200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -184763,12 +185130,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -184776,6 +185145,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "cultivating-the-understory-building-resilient-daos", + "sourceId": "NRHH9B", + "title": "Cultivating the Understory : Building Resilient DAOs", + "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": true, + "doNotRecord": false, + "tags": [ + "Coordination", + "DAO", + "Vision", + "resiliency", + "Coordination", + "DAO", + "Vision" + ], + "keywords": [ + "Culture", + "Resilience" + ], + "duration": 1569, + "language": "en", + "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d", + "sources_youtubeId": "274Uyrxv6uI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c", + "resources_slides": null, + "speakers": [ + "songyi-lee" + ] + }, + "vector": [ 0, 0, 0, @@ -184787,6 +185204,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -184803,7 +185221,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -184828,7 +185245,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -184989,6 +185405,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -185620,6 +186037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -185673,11 +186091,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -185752,6 +186172,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -185921,14 +186342,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -185936,54 +186355,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "cultivating-the-understory-building-resilient-daos", - "sourceId": "NRHH9B", - "title": "Cultivating the Understory : Building Resilient DAOs", - "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": true, - "doNotRecord": false, - "tags": [ - "Coordination", - "DAO", - "Vision", - "resiliency", - "Coordination", - "DAO", - "Vision" - ], - "keywords": [ - "Culture", - "Resilience" - ], - "duration": 1569, - "language": "en", - "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d", - "sources_youtubeId": "274Uyrxv6uI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c", - "resources_slides": null, - "speakers": [ - "songyi-lee" - ] - }, - "vector": [ 0, 0, 0, @@ -185995,7 +186366,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -186130,12 +186500,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -186143,11 +186515,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages", + "sourceId": "NMKQYY", + "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages", + "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "History", + "Culture" + ], + "tags": [ + "Governance", + "Network State", + "Security", + "culture", + "Governance", + "Network State", + "Security" + ], + "language": "en", + "speakers": [ + "evin-mcmullen" + ], + "eventId": "devcon-7", + "slot_start": 1731493800000, + "slot_end": 1731494400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -186195,7 +186607,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -186291,6 +186702,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -186824,7 +187236,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -186878,16 +187289,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, + 6, 0, 0, 0, @@ -186934,6 +187344,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -186959,7 +187370,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -186983,6 +187393,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -187123,6 +187534,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -187287,14 +187699,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -187302,51 +187712,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages", - "sourceId": "NMKQYY", - "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages", - "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "History", - "Culture" - ], - "tags": [ - "Governance", - "Network State", - "Security", - "culture", - "Governance", - "Network State", - "Security" - ], - "language": "en", - "speakers": [ - "evin-mcmullen" - ], - "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731494400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -187488,22 +187858,65 @@ 0, 0, 0, - 6, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter", + "sourceId": "QPQZJR", + "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter", + "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Latency" + ], + "tags": [ + "latency", + "Censorship Resistance", + "Ethereum Roadmap", + "Not financial" + ], + "language": "en", + "speakers": [ + "sebastian-buergel" + ], + "eventId": "devcon-7", + "slot_start": 1731493200000, + "slot_end": 1731493800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -187711,6 +188124,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -188080,7 +188494,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -188127,7 +188540,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -188176,7 +188588,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -188317,7 +188728,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -188392,6 +188802,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188437,6 +188848,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188480,6 +188892,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -188644,77 +189058,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter", - "sourceId": "QPQZJR", - "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter", - "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Latency" - ], - "tags": [ - "latency", - "Censorship Resistance", - "Ethereum Roadmap", - "Not financial" - ], - "language": "en", - "speakers": [ - "sebastian-buergel" - ], - "eventId": "devcon-7", - "slot_start": 1731493200000, - "slot_end": 1731493800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -188873,6 +189216,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188881,6 +189225,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -188888,7 +189233,37 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "dacc-closing-panel", + "sourceId": "HTKUVS", + "title": "d/acc closing panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "vitalik-buterin", + "eli-dourado" + ], + "eventId": "devcon-7", + "slot_start": 1731582600000, + "slot_end": 1731584400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -188906,7 +189281,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -189083,6 +189457,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -189101,6 +189476,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -189581,7 +189957,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -189627,7 +190002,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -189671,8 +190045,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -189995,7 +190367,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -190004,7 +190375,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -190012,37 +190382,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "dacc-closing-panel", - "sourceId": "HTKUVS", - "title": "d/acc closing panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "vitalik-buterin", - "eli-dourado" - ], - "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731584400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -190228,14 +190568,15 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -190243,6 +190584,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds", + "sourceId": "3E7R7G", + "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds", + "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "DAO", + "Governance", + "Decentralization", + "cybernetics", + "DAO", + "Decentralization", + "Governance" + ], + "keywords": [ + "Cryptolaw", + "cybernetics" + ], + "duration": 1641, + "language": "en", + "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012", + "sources_youtubeId": "2pYy07uUG4c", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324013a168eb5355d6509.vtt", + "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel", + "eventId": "devcon-7", + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY", + "resources_slides": null, + "speakers": [ + "gabriel-shapiro" + ] + }, + "vector": [ 0, 0, 0, @@ -190458,6 +190847,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -191081,10 +191471,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -191222,6 +191615,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -191343,70 +191737,11 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds", - "sourceId": "3E7R7G", - "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds", - "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "DAO", - "Governance", - "Decentralization", - "cybernetics", - "DAO", - "Decentralization", - "Governance" - ], - "keywords": [ - "Cryptolaw", - "cybernetics" - ], - "duration": 1641, - "language": "en", - "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012", - "sources_youtubeId": "2pYy07uUG4c", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324013a168eb5355d6509.vtt", - "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY", - "resources_slides": null, - "speakers": [ - "gabriel-shapiro" - ] - }, - "vector": [ 0, 0, 0, @@ -191418,7 +191753,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -191603,10 +191937,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -191618,10 +191954,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "daos-unmasked-the-hard-truths-behind-the-hype", + "sourceId": "ZSSKBL", + "title": "DAOs Unmasked: The Hard Truths Behind the Hype", + "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "tags": [ + "Coordination", + "DAO", + "Governance", + "Regulation", + "Coordination", + "DAO", + "Governance" + ], + "keywords": [ + "Decentralization Theater", + "Regulation" + ], + "duration": 1670, + "language": "en", + "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c", + "sources_youtubeId": "pdlMrmUxpSg", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731393000000, + "slot_end": 1731394800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k", + "resources_slides": null, + "speakers": [ + "lefteris-karapetsas" + ] + }, + "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -191630,6 +192013,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -191834,6 +192218,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -192242,13 +192627,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -192386,7 +192768,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -192460,15 +192841,18 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -192516,6 +192900,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -192708,12 +193093,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -192725,54 +193108,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "daos-unmasked-the-hard-truths-behind-the-hype", - "sourceId": "ZSSKBL", - "title": "DAOs Unmasked: The Hard Truths Behind the Hype", - "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "tags": [ - "Coordination", - "DAO", - "Governance", - "Regulation", - "Coordination", - "DAO", - "Governance" - ], - "keywords": [ - "Decentralization Theater", - "Regulation" - ], - "duration": 1670, - "language": "en", - "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c", - "sources_youtubeId": "pdlMrmUxpSg", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731394800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k", - "resources_slides": null, - "speakers": [ - "lefteris-karapetsas" - ] - }, - "vector": [ 0, 0, 0, @@ -192784,7 +193119,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -192975,12 +193309,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -192988,11 +193324,49 @@ 0, 0, 0, - 6, + 0 + ] + }, + { + "session": { + "id": "dare-to-be-solo-staking", + "sourceId": "ZMSNHW", + "title": "Dare to be Solo Staking", + "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "staking" + ], + "tags": [ + "Staking", + "Home staking", + "Best Practices", + "Public good", + "Best Practices", + "Home staking", + "Public good" + ], + "language": "en", + "speakers": [ + "jerome-de-tychey" + ], + "eventId": "devcon-7", + "slot_start": 1731642000000, + "slot_end": 1731642600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -193205,6 +193579,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -193608,18 +193983,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -193667,7 +194039,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -193765,6 +194136,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -193819,6 +194191,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -193841,6 +194214,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -193860,6 +194234,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -194076,14 +194451,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -194091,49 +194464,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "dare-to-be-solo-staking", - "sourceId": "ZMSNHW", - "title": "Dare to be Solo Staking", - "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "staking" - ], - "tags": [ - "Staking", - "Home staking", - "Best Practices", - "Public good", - "Best Practices", - "Home staking", - "Public good" - ], - "language": "en", - "speakers": [ - "jerome-de-tychey" - ], - "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731642600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -194335,20 +194669,70 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, - 6, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "dark-daos-and-private-coordination", + "sourceId": "SX8B9E", + "title": "Dark DAOs and Private Coordination", + "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "Coordination", + "DAO", + "Privacy", + "dark", + "Coordination", + "DAO", + "Privacy" + ], + "keywords": [ + "encumbrance", + "TEE", + "Dark DAO" + ], + "duration": 1515, + "language": "en", + "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e", + "sources_youtubeId": "iU-2dwVVagk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt", + "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.", + "eventId": "devcon-7", + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY", + "resources_slides": null, + "speakers": [ + "sarah-allen" + ] + }, + "vector": [ 0, 0, 0, @@ -194360,6 +194744,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -194566,6 +194951,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -194899,7 +195285,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -194954,7 +195339,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -194977,7 +195361,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -194997,7 +195380,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -195195,6 +195577,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -195210,6 +195593,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -195247,6 +195631,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -195332,6 +195717,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -195432,14 +195818,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -195447,55 +195831,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "dark-daos-and-private-coordination", - "sourceId": "SX8B9E", - "title": "Dark DAOs and Private Coordination", - "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "Coordination", - "DAO", - "Privacy", - "dark", - "Coordination", - "DAO", - "Privacy" - ], - "keywords": [ - "encumbrance", - "TEE", - "Dark DAO" - ], - "duration": 1515, - "language": "en", - "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e", - "sources_youtubeId": "iU-2dwVVagk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt", - "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY", - "resources_slides": null, - "speakers": [ - "sarah-allen" - ] - }, - "vector": [ 0, 0, 0, @@ -195507,7 +195842,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -195704,14 +196038,57 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat", + "sourceId": "7QAKPP", + "title": "Dark winter: why the risk of unnatural pandemics is an existential threat", + "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Biosafety" + ], + "tags": [ + "Collective Intelligence", + "Public good", + "Security" + ], + "language": "en", + "speakers": [ + "raina-macintyre" + ], + "eventId": "devcon-7", + "slot_start": 1731568500000, + "slot_end": 1731569400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU" + }, + "vector": [ 0, 6, 0, @@ -195931,6 +196308,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -196336,7 +196714,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -196352,7 +196729,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -196390,7 +196766,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -196457,6 +196832,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -196476,7 +196852,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -196491,6 +196866,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -196565,6 +196941,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -196797,12 +197175,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -196814,42 +197190,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat", - "sourceId": "7QAKPP", - "title": "Dark winter: why the risk of unnatural pandemics is an existential threat", - "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Biosafety" - ], - "tags": [ - "Collective Intelligence", - "Public good", - "Security" - ], - "language": "en", - "speakers": [ - "raina-macintyre" - ], - "eventId": "devcon-7", - "slot_start": 1731568500000, - "slot_end": 1731569400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -197055,12 +197396,60 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, 0, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society", + "sourceId": "FKED87", + "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.", + "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "crypto-anarchy", + "agorism" + ], + "tags": [ + "Privacy", + "Anonymity", + "ZKP", + "agorism", + "Anonymity", + "Privacy", + "ZKP" + ], + "language": "en", + "speakers": [ + "amir-taaki" + ], + "eventId": "devcon-7", + "slot_start": 1731490200000, + "slot_end": 1731491400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE" + }, + "vector": [ 0, 0, 0, @@ -197281,6 +197670,31 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -197587,7 +198001,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -197621,7 +198034,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -197696,7 +198108,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -197808,6 +198219,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -197841,6 +198268,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -197875,6 +198310,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -197996,6 +198435,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -198151,76 +198594,6 @@ 0, 0, 0, - 2, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society", - "sourceId": "FKED87", - "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.", - "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "crypto-anarchy", - "agorism" - ], - "tags": [ - "Privacy", - "Anonymity", - "ZKP", - "agorism", - "Anonymity", - "Privacy", - "ZKP" - ], - "language": "en", - "speakers": [ - "amir-taaki" - ], - "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731491400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -198384,12 +198757,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -198397,8 +198772,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "data-driven-tokenomics-analyzing-incentives-in-action", + "sourceId": "LPDCMK", + "title": "Data-Driven Tokenomics: Analyzing Incentives in Action", + "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "data analytics", + "growth analytics", + "user behaviour" + ], + "tags": [ + "macro/micro economics", + "Tokenomics", + "User Research" + ], + "language": "en", + "speakers": [ + "lisa-jy-tan" + ], + "eventId": "devcon-7", + "slot_start": 1731484200000, + "slot_end": 1731484800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -198424,7 +198836,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -198618,6 +199029,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -198970,7 +199382,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -199019,7 +199430,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -199061,7 +199471,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -199229,6 +199638,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -199356,6 +199766,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -199508,14 +199919,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 2, 0, 0, 0, @@ -199523,45 +199926,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "data-driven-tokenomics-analyzing-incentives-in-action", - "sourceId": "LPDCMK", - "title": "Data-Driven Tokenomics: Analyzing Incentives in Action", - "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "data analytics", - "growth analytics", - "user behaviour" - ], - "tags": [ - "macro/micro economics", - "Tokenomics", - "User Research" - ], - "language": "en", - "speakers": [ - "lisa-jy-tan" - ], - "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731484800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -199749,11 +200115,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -199762,6 +200130,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations", + "sourceId": "LVVTKU", + "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations", + "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Tooling", + "debugging", + "testing" + ], + "tags": [ + "DevEx", + "Security", + "Best Practices", + "Testing", + "Best Practices", + "DevEx", + "Security", + "Testing" + ], + "language": "en", + "speakers": [ + "aellison-cassimiro" + ], + "eventId": "devcon-7", + "slot_start": 1731656400000, + "slot_end": 1731657000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM" + }, + "vector": [ + 6, 0, 0, 0, @@ -199779,7 +200189,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -199984,6 +200393,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -200342,7 +200752,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -200385,7 +200794,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -200506,6 +200914,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -200513,7 +200922,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -200536,6 +200944,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -200747,6 +201157,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -200862,13 +201273,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -200877,49 +201286,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations", - "sourceId": "LVVTKU", - "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations", - "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Tooling", - "debugging", - "testing" - ], - "tags": [ - "DevEx", - "Security", - "Best Practices", - "Testing", - "Best Practices", - "DevEx", - "Security", - "Testing" - ], - "language": "en", - "speakers": [ - "aellison-cassimiro" - ], - "eventId": "devcon-7", - "slot_start": 1731656400000, - "slot_end": 1731657000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM" - }, - "vector": [ - 6, - 0, 0, 0, 0, @@ -201110,11 +201476,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -201125,9 +201493,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status", + "sourceId": "JLWSZ7", + "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status", + "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Debugging" + ], + "tags": [ + "Developer Infrastructure", + "Tooling", + "Best Practices", + "debugging", + "Best Practices", + "Developer Infrastructure", + "Tooling" + ], + "language": "en", + "speakers": [ + "g-nick-gnidan" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -201139,7 +201546,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -201348,6 +201754,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -201657,7 +202064,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -201687,8 +202093,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -201891,6 +202295,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -201923,6 +202328,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -202112,6 +202518,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -202219,13 +202626,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -202236,50 +202641,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status", - "sourceId": "JLWSZ7", - "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status", - "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Debugging" - ], - "tags": [ - "Developer Infrastructure", - "Tooling", - "Best Practices", - "debugging", - "Best Practices", - "Developer Infrastructure", - "Tooling" - ], - "language": "en", - "speakers": [ - "g-nick-gnidan" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU" - }, - "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, 0, 0, 0, @@ -202478,6 +202839,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -202490,6 +202853,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "debunking-myths-about-building-out-of-sea", + "sourceId": "CDVQ7R", + "title": "Debunking Myths about Building out of SEA", + "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Local/SEA", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Build", + "Myth", + "Local" + ], + "tags": [ + "Local Impact", + "SEA", + "myths", + "SEA" + ], + "language": "en", + "speakers": [ + "matthew-tan", + "harith-kamarul", + "tn-lee", + "loi-luu" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731650400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY" + }, + "vector": [ 0, 0, 0, @@ -202714,6 +203117,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -203034,7 +203441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -203044,7 +203450,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -203067,7 +203472,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -203257,7 +203661,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -203478,6 +203881,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -203578,8 +203984,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -203591,54 +203995,12 @@ 0, 0, 0, - 0, - 0 - ] - }, - { - "session": { - "id": "debunking-myths-about-building-out-of-sea", - "sourceId": "CDVQ7R", - "title": "Debunking Myths about Building out of SEA", - "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Local/SEA", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Build", - "Myth", - "Local" - ], - "tags": [ - "Local Impact", - "SEA", - "myths", - "SEA" - ], - "language": "en", - "speakers": [ - "matthew-tan", - "harith-kamarul", - "tn-lee", - "loi-luu" - ], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731650400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -203838,6 +204200,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -203851,19 +204214,43 @@ 0, 0, 0, + 2, + 0 + ] + }, + { + "session": { + "id": "deca-12x", + "sourceId": "WYESYA", + "title": "Deca 12x", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I" + }, + "vector": [ 0, 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -204616,9 +205003,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -204935,7 +205319,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -204949,33 +205332,6 @@ 0, 0, 0, - 2, - 0 - ] - }, - { - "session": { - "id": "deca-12x", - "sourceId": "WYESYA", - "title": "Deca 12x", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I" - }, - "vector": [ 0, 0, 0, @@ -204985,7 +205341,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -205192,8 +205547,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -205206,6 +205563,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "decentralize-your-sequencer-a-guide-for-l2s", + "sourceId": "BNBCVC", + "title": "Decentralize your sequencer -- A guide for L2’s", + "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Sequencer", + "Decentralisation" + ], + "tags": [ + "Zk Rollups", + "Sufficient decentralization", + "Decentralization", + "sequencer", + "Decentralization", + "Sufficient decentralization", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "joe-andrews" + ], + "eventId": "devcon-7", + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M" + }, + "vector": [ 0, 0, 0, @@ -205213,6 +205609,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -205433,6 +205830,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -206016,6 +206414,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -206048,6 +206447,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -206058,6 +206458,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -206101,6 +206502,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -206278,10 +206688,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -206294,45 +206702,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "decentralize-your-sequencer-a-guide-for-l2s", - "sourceId": "BNBCVC", - "title": "Decentralize your sequencer -- A guide for L2’s", - "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Sequencer", - "Decentralisation" - ], - "tags": [ - "Zk Rollups", - "Sufficient decentralization", - "Decentralization", - "sequencer", - "Decentralization", - "Sufficient decentralization", - "Zk Rollups" - ], - "language": "en", - "speakers": [ - "joe-andrews" - ], - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M" - }, - "vector": [ 0, 0, 0, @@ -206340,7 +206709,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -206539,9 +206907,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -206554,6 +206924,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "decentralized-outcome-funding-for-investigative-reporters", + "sourceId": "SJE7VP", + "title": "Decentralized Outcome Funding for Investigative Reporters", + "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Hypercerts" + ], + "tags": [ + "Effective Altruism", + "Ethereum for Good", + "Regenerative Applications", + "hypercerts", + "Effective Altruism", + "Ethereum for Good", + "Regenerative Applications" + ], + "language": "en", + "speakers": [ + "devansh-mehta" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731467700000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg" + }, + "vector": [ 0, 0, 0, @@ -206783,6 +207191,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -207141,7 +207550,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207174,7 +207582,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207185,7 +207592,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207229,7 +207635,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -207426,10 +207831,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -207488,6 +207895,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207545,6 +207953,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -207634,11 +208043,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -207651,51 +208058,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "decentralized-outcome-funding-for-investigative-reporters", - "sourceId": "SJE7VP", - "title": "Decentralized Outcome Funding for Investigative Reporters", - "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Hypercerts" - ], - "tags": [ - "Effective Altruism", - "Ethereum for Good", - "Regenerative Applications", - "hypercerts", - "Effective Altruism", - "Ethereum for Good", - "Regenerative Applications" - ], - "language": "en", - "speakers": [ - "devansh-mehta" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731467700000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -207901,11 +208269,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -207913,6 +208283,43 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks", + "sourceId": "NWSNWX", + "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks", + "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EIP 4444s", + "Portal Network", + "Decentralization" + ], + "tags": [ + "Decentralization", + "Decentralization", + "Light Clients" + ], + "language": "en", + "speakers": [ + "kolby-moroz-liebl" + ], + "eventId": "devcon-7", + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk" + }, + "vector": [ 0, 0, 0, @@ -208143,6 +208550,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -208554,12 +208964,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -208618,7 +209026,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -208758,6 +209165,32 @@ 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, @@ -208992,13 +209425,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -209007,47 +209438,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks", - "sourceId": "NWSNWX", - "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks", - "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EIP 4444s", - "Portal Network", - "Decentralization" - ], - "tags": [ - "Decentralization", - "Decentralization", - "Light Clients" - ], - "language": "en", - "speakers": [ - "kolby-moroz-liebl" - ], - "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -209233,7 +209627,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -209246,12 +209642,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy", + "sourceId": "STX9DW", + "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy", + "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Decentralization", + "Ethereum for Good", + "Network State" + ], + "language": "en", + "speakers": [ + "joe-lubin" + ], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731582000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -209272,7 +209701,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -209477,6 +209905,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -209802,7 +210231,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -209884,7 +210312,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -210037,6 +210464,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -210091,6 +210519,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -210114,6 +210543,20 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -210346,9 +210789,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -210361,45 +210802,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy", - "sourceId": "STX9DW", - "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy", - "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Decentralization", - "Ethereum for Good", - "Network State" - ], - "language": "en", - "speakers": [ - "joe-lubin" - ], - "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -210571,9 +210979,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -210586,12 +210996,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya", + "sourceId": "SRYTXY", + "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya", + "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ReFi", + "Emerging Markets" + ], + "tags": [ + "Use Cases", + "Ethereum for Good", + "Local Impact", + "market", + "emerging", + "Ethereum for Good", + "Local Impact", + "Use Cases" + ], + "language": "en", + "speakers": [ + "anna-stone", + "damaris-njoroge" + ], + "eventId": "devcon-7", + "slot_start": 1731409200000, + "slot_end": 1731411000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -210623,7 +211075,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -210818,6 +211269,15 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -211179,7 +211639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -211234,7 +211693,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -211258,7 +211716,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -211359,6 +211816,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -211398,6 +211859,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -211443,6 +211906,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -211560,6 +212025,70 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -211694,89 +212223,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya", - "sourceId": "SRYTXY", - "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya", - "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ReFi", - "Emerging Markets" - ], - "tags": [ - "Use Cases", - "Ethereum for Good", - "Local Impact", - "market", - "emerging", - "Ethereum for Good", - "Local Impact", - "Use Cases" - ], - "language": "en", - "speakers": [ - "anna-stone", - "damaris-njoroge" - ], - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ" - }, - "vector": [ - 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, @@ -211898,12 +212344,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -211911,12 +212359,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "decentralizing-the-internets-collaboration-layer", + "sourceId": "NZMSMG", + "title": "Decentralizing the Internet's collaboration layer", + "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "mutual", + "aid" + ], + "tags": [ + "Coordination", + "Privacy", + "Use Cases", + "mutual", + "aid", + "Coordination", + "Privacy", + "Use Cases" + ], + "language": "en", + "speakers": [ + "andreas-tsamados" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731556200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -211983,8 +212472,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -212146,6 +212633,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -212527,7 +213015,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212570,7 +213057,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212617,7 +213103,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212740,7 +213225,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -212775,6 +213259,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -212812,6 +213297,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -212906,6 +213392,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -213055,14 +213543,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -213070,53 +213556,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "decentralizing-the-internets-collaboration-layer", - "sourceId": "NZMSMG", - "title": "Decentralizing the Internet's collaboration layer", - "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "mutual", - "aid" - ], - "tags": [ - "Coordination", - "Privacy", - "Use Cases", - "mutual", - "aid", - "Coordination", - "Privacy", - "Use Cases" - ], - "language": "en", - "speakers": [ - "andreas-tsamados" - ], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -213259,6 +213704,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -213267,6 +213713,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -213274,6 +213721,37 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1", + "sourceId": "ZAKUY3", + "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1", + "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "julien", + "grant-southey", + "gregskrileth", + "thomas-clowes" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731486600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ" + }, + "vector": [ 0, 0, 0, @@ -213281,6 +213759,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -213343,7 +213822,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -213509,6 +213987,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -213928,7 +214410,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -213966,7 +214447,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -214004,7 +214484,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -214099,8 +214578,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -214411,7 +214888,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -214420,7 +214896,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -214428,37 +214903,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1", - "sourceId": "ZAKUY3", - "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1", - "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "julien", - "grant-southey", - "gregskrileth", - "thomas-clowes" - ], - "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731486600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ" - }, - "vector": [ 0, 0, 0, @@ -214466,7 +214910,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -214617,6 +215060,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -214629,6 +215074,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients", + "sourceId": "D3XZKF", + "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients", + "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Fork choice", + "model based testing", + "fuzz testing" + ], + "tags": [ + "Core Protocol", + "Fuzzing", + "Testing", + "Core Protocol", + "Testing" + ], + "language": "en", + "speakers": [ + "mikhail-kalinin", + "alex-vlasov" + ], + "eventId": "devcon-7", + "slot_start": 1731578400000, + "slot_end": 1731580200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q" + }, + "vector": [ + 6, 0, 0, 0, @@ -214693,10 +215178,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -214871,6 +215352,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -215374,6 +215857,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -215391,6 +215875,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -215614,6 +216099,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -215763,8 +216253,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -215777,46 +216265,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients", - "sourceId": "D3XZKF", - "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients", - "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Fork choice", - "model based testing", - "fuzz testing" - ], - "tags": [ - "Core Protocol", - "Fuzzing", - "Testing", - "Core Protocol", - "Testing" - ], - "language": "en", - "speakers": [ - "mikhail-kalinin", - "alex-vlasov" - ], - "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731580200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q" - }, - "vector": [ - 6, 0, 0, 0, @@ -215970,6 +216418,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -215979,6 +216435,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "deep-dive-the-lp-pricing", + "sourceId": "CDPRCK", + "title": "Deep Dive the LP Pricing", + "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Math", + "Oracle price", + "DeFi" + ], + "tags": [ + "Security", + "Mechanism design", + "Economics", + "defi", + "Economics", + "Mechanism design", + "Security" + ], + "language": "en", + "speakers": [ + "nipun-pitimanaaree" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731489000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8" + }, + "vector": [ + 0, + 0, + 6, 0, 0, 0, @@ -216054,8 +216553,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -216219,6 +216716,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -216556,7 +217054,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -216574,7 +217071,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -216722,12 +217218,14 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -216755,6 +217253,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -216798,7 +217297,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -216913,6 +217411,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -217117,11 +217616,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -217134,49 +217631,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "deep-dive-the-lp-pricing", - "sourceId": "CDPRCK", - "title": "Deep Dive the LP Pricing", - "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Math", - "Oracle price", - "DeFi" - ], - "tags": [ - "Security", - "Mechanism design", - "Economics", - "defi", - "Economics", - "Mechanism design", - "Security" - ], - "language": "en", - "speakers": [ - "nipun-pitimanaaree" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -217327,6 +217783,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -217339,6 +217797,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "defcon-at-devcon-a-table-top-experience", + "sourceId": "P9DRXY", + "title": "Defcon at Devcon: A table top experience", + "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.", + "track": "Security", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Tabletop", + "Incident Response", + "Threat Intelligence" + ], + "tags": [ + "Best Practices", + "Hacks", + "Event monitoring", + "threat", + "intelligence", + "Best Practices", + "Event monitoring", + "Hacks" + ], + "language": "en", + "speakers": [ + "heidi-wilder", + "peter-kacherginsky" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731645900000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0" + }, + "vector": [ + 6, 0, 0, 0, @@ -217414,7 +217915,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -217581,6 +218081,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -217913,14 +218415,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -217948,7 +218448,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -218106,7 +218605,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -218115,6 +218613,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -218335,6 +218834,10 @@ 0, 0, 0, + 2, + 2, + 2, + 2, 0, 0, 0, @@ -218478,73 +218981,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "defcon-at-devcon-a-table-top-experience", - "sourceId": "P9DRXY", - "title": "Defcon at Devcon: A table top experience", - "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.", - "track": "Security", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Tabletop", - "Incident Response", - "Threat Intelligence" - ], - "tags": [ - "Best Practices", - "Hacks", - "Event monitoring", - "threat", - "intelligence", - "Best Practices", - "Event monitoring", - "Hacks" - ], - "language": "en", - "speakers": [ - "heidi-wilder", - "peter-kacherginsky" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731645900000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0" - }, - "vector": [ - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -218708,9 +219144,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -218723,6 +219161,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind", + "sourceId": "9KWRRJ", + "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind", + "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Clear signing", + "transactions" + ], + "tags": [ + "Open Source Software", + "Security", + "UI/UX" + ], + "language": "en", + "speakers": [ + "charles-guillemet" + ], + "eventId": "devcon-7", + "slot_start": 1731409200000, + "slot_end": 1731409800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg" + }, + "vector": [ + 6, 0, 0, 0, @@ -218775,8 +219249,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -218968,6 +219440,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -219304,7 +219777,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -219467,6 +219939,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -219526,25 +219999,6 @@ 0, 0, 2, - 2, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -219583,6 +220037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -219835,11 +220290,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -219852,52 +220305,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind", - "sourceId": "9KWRRJ", - "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind", - "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Clear signing", - "transactions" - ], - "tags": [ - "Open Source Software", - "Security", - "UI/UX" - ], - "language": "en", - "speakers": [ - "charles-guillemet" - ], - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731409800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg" - }, - "vector": [ - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -220094,11 +220501,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -220109,6 +220518,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "defragmenting-ethereum-interoperability-and-the-superchain", + "sourceId": "YEQLR8", + "title": "Defragmenting Ethereum - Interoperability and the Superchain", + "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "superchain", + "OP Stack", + "optimism" + ], + "tags": [ + "optimism" + ], + "language": "en", + "speakers": [ + "karl-floersch" + ], + "eventId": "devcon-7", + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA" + }, + "vector": [ 0, 0, 0, @@ -220116,6 +220559,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -220130,7 +220574,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -220354,6 +220797,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -220626,7 +221070,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -220685,7 +221128,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -220724,7 +221166,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -221110,6 +221551,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -221188,13 +221630,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -221205,40 +221645,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "defragmenting-ethereum-interoperability-and-the-superchain", - "sourceId": "YEQLR8", - "title": "Defragmenting Ethereum - Interoperability and the Superchain", - "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "superchain", - "OP Stack", - "optimism" - ], - "tags": [ - "optimism" - ], - "language": "en", - "speakers": [ - "karl-floersch" - ], - "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA" - }, - "vector": [ 0, 0, 0, @@ -221246,7 +221652,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -221452,9 +221857,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -221467,6 +221874,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "degen-incentives-for-regen-outcomes", + "sourceId": "MNWVFW", + "title": "Degen incentives for Regen outcomes", + "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.", + "track": "Coordination", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Ethereum Culture", + "Ethereum Community", + "degens🤝regens" + ], + "tags": [ + "Ethereum for Good", + "Regenerative Applications", + "Product-market fit", + "regen", + "degens", + "Ethereum for Good", + "Product-market fit", + "Regenerative Applications" + ], + "language": "en", + "speakers": [ + "griff-green", + "nico-gallardo", + "james-kiernan", + "lauren-luz" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731646800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA" + }, + "vector": [ 0, 0, 0, @@ -221478,12 +221929,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -221713,6 +222164,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -222234,7 +222689,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -222265,6 +222719,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -222332,10 +222787,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -222461,6 +222918,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -222540,11 +222999,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -222557,50 +223014,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "degen-incentives-for-regen-outcomes", - "sourceId": "MNWVFW", - "title": "Degen incentives for Regen outcomes", - "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.", - "track": "Coordination", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Ethereum Culture", - "Ethereum Community", - "degens🤝regens" - ], - "tags": [ - "Ethereum for Good", - "Regenerative Applications", - "Product-market fit", - "regen", - "degens", - "Ethereum for Good", - "Product-market fit", - "Regenerative Applications" - ], - "language": "en", - "speakers": [ - "griff-green", - "nico-gallardo", - "james-kiernan", - "lauren-luz" - ], - "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731646800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA" - }, - "vector": [ 0, 0, 0, @@ -222612,7 +223025,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -222813,12 +223225,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -222826,8 +223240,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "demand-based-recurring-fees-in-practice", + "sourceId": "GWBWPE", + "title": "Demand-based recurring fees in practice", + "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "pricing" + ], + "tags": [ + "Economics", + "Mechanism design", + "Quadratic Voting" + ], + "language": "en", + "speakers": [ + "timdaub" + ], + "eventId": "devcon-7", + "slot_start": 1731495000000, + "slot_end": 1731496800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -222846,10 +223295,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -223079,6 +223524,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -223398,7 +223844,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -223466,12 +223911,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -223581,6 +224024,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -223597,8 +224041,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -223610,6 +224052,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -223785,6 +224228,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -223904,14 +224348,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -223919,43 +224361,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "demand-based-recurring-fees-in-practice", - "sourceId": "GWBWPE", - "title": "Demand-based recurring fees in practice", - "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "pricing" - ], - "tags": [ - "Economics", - "Mechanism design", - "Quadratic Voting" - ], - "language": "en", - "speakers": [ - "timdaub" - ], - "eventId": "devcon-7", - "slot_start": 1731495000000, - "slot_end": 1731496800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -224172,9 +224579,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -224187,6 +224596,59 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "demystifying-smart-contract-security-facts-and-fallacies", + "sourceId": "VXRSPU", + "title": "Demystifying Smart Contract Security: Facts & Fallacies", + "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.", + "track": "Security", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Smart", + "Contract", + "Security" + ], + "tags": [ + "Security", + "Best Practices", + "Hacks", + "Formal Verification", + "Auditing", + "Bounties", + "smart", + "contracts", + "Auditing", + "Best Practices", + "Bounties", + "Formal Verification", + "Hacks", + "Security" + ], + "language": "en", + "speakers": [ + "josselin-feist", + "0xrajeev", + "matthias-egli", + "mehdi-zerouali", + "mooly-sagiv", + "harikrishnan-mulackal" + ], + "eventId": "devcon-7", + "slot_start": 1731657600000, + "slot_end": 1731661200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g" + }, + "vector": [ + 6, 0, 0, 0, @@ -224202,7 +224664,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -224438,6 +224899,12 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -224699,7 +225166,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -224727,7 +225193,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -224903,7 +225368,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -224927,6 +225391,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -224957,6 +225422,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -225077,6 +225543,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -225123,6 +225590,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -225175,12 +225643,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -225254,11 +225726,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -225271,59 +225741,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "demystifying-smart-contract-security-facts-and-fallacies", - "sourceId": "VXRSPU", - "title": "Demystifying Smart Contract Security: Facts & Fallacies", - "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.", - "track": "Security", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Smart", - "Contract", - "Security" - ], - "tags": [ - "Security", - "Best Practices", - "Hacks", - "Formal Verification", - "Auditing", - "Bounties", - "smart", - "contracts", - "Auditing", - "Best Practices", - "Bounties", - "Formal Verification", - "Hacks", - "Security" - ], - "language": "en", - "speakers": [ - "josselin-feist", - "0xrajeev", - "matthias-egli", - "mehdi-zerouali", - "mooly-sagiv", - "harikrishnan-mulackal" - ], - "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731661200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g" - }, - "vector": [ - 6, 0, 0, 0, @@ -225536,11 +225953,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -225551,10 +225970,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "demystifying-solo-staking-struggles", + "sourceId": "9KV8UQ", + "title": "Demystifying solo staking struggles", + "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "keywords": [ + "beginners" + ], + "tags": [ + "Best Practices", + "Home staking", + "Staking" + ], + "language": "en", + "speakers": [ + "remy-roy" + ], + "eventId": "devcon-7", + "slot_start": 1731642600000, + "slot_end": 1731643200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -225573,12 +226027,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -225813,6 +226261,20 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -226062,7 +226524,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -226093,7 +226554,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226214,7 +226674,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226261,7 +226720,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226314,7 +226772,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -226322,8 +226779,6 @@ 0, 0, 2, - 2, - 2, 0, 0, 0, @@ -226378,6 +226833,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -226418,6 +226876,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -226624,13 +227083,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -226641,45 +227098,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "demystifying-solo-staking-struggles", - "sourceId": "9KV8UQ", - "title": "Demystifying solo staking struggles", - "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "keywords": [ - "beginners" - ], - "tags": [ - "Best Practices", - "Home staking", - "Staking" - ], - "language": "en", - "speakers": [ - "remy-roy" - ], - "eventId": "devcon-7", - "slot_start": 1731642600000, - "slot_end": 1731643200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -226889,6 +227311,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -226896,17 +227319,65 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "depin-pushing-decentralization-beyond-blockchain", + "sourceId": "Q8QPSF", + "title": "DePIN: Pushing Decentralization Beyond Blockchain", + "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Distributed Systems", + "Physical Infrastructure", + "Real Time Communication (RTC)" + ], + "tags": [ + "Architecture", + "Decentralization", + "DePIN", + "Tokenomics", + "communication", + "real", + "time", + "rtc", + "Architecture", + "Decentralization", + "DePIN", + "Tokenomics" + ], + "language": "en", + "speakers": [ + "akshit-gupta" + ], + "eventId": "devcon-7", + "slot_start": 1731579600000, + "slot_end": 1731580200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -226931,7 +227402,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -227159,6 +227629,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -227445,7 +227920,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227500,7 +227974,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227543,7 +228016,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -227664,6 +228136,30 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, @@ -227680,6 +228176,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -227716,6 +228216,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -227875,6 +228376,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -227978,87 +228482,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "depin-pushing-decentralization-beyond-blockchain", - "sourceId": "Q8QPSF", - "title": "DePIN: Pushing Decentralization Beyond Blockchain", - "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Distributed Systems", - "Physical Infrastructure", - "Real Time Communication (RTC)" - ], - "tags": [ - "Architecture", - "Decentralization", - "DePIN", - "Tokenomics", - "communication", - "real", - "time", - "rtc", - "Architecture", - "Decentralization", - "DePIN", - "Tokenomics" - ], - "language": "en", - "speakers": [ - "akshit-gupta" - ], - "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -228253,11 +228676,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -228268,12 +228693,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "desci-co-designing-the-future-of-science", + "sourceId": "DCHCYW", + "title": "DeSci: Co-Designing The Future of Science", + "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Academic", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Science" + ], + "tags": [ + "science", + "Data Availability", + "DeSci" + ], + "language": "en", + "speakers": [ + "erin-magennis" + ], + "eventId": "devcon-7", + "slot_start": 1731659400000, + "slot_end": 1731660000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -228295,7 +228755,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -228527,6 +228986,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -228799,7 +229259,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -228821,7 +229280,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -228839,7 +229297,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -228879,7 +229336,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -229039,9 +229495,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -229084,6 +229537,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -229150,6 +229604,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -229280,6 +229735,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -229339,13 +229795,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -229356,47 +229810,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "desci-co-designing-the-future-of-science", - "sourceId": "DCHCYW", - "title": "DeSci: Co-Designing The Future of Science", - "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Academic", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Science" - ], - "tags": [ - "science", - "Data Availability", - "DeSci" - ], - "language": "en", - "speakers": [ - "erin-magennis" - ], - "eventId": "devcon-7", - "slot_start": 1731659400000, - "slot_end": 1731660000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -229613,6 +230032,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -229625,15 +230045,55 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science", + "sourceId": "MZ3RLT", + "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?", + "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Impact" + ], + "tags": [ + "Permissionless", + "Use Cases", + "DeSci", + "impact", + "DeSci", + "Permissionless", + "Use Cases" + ], + "language": "en", + "speakers": [ + "paul-kohlhaas" + ], + "eventId": "devcon-7", + "slot_start": 1731658800000, + "slot_end": 1731659400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -229648,7 +230108,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -229888,6 +230347,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -230196,7 +230656,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -230263,7 +230722,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -230394,7 +230852,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -230452,6 +230909,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -230506,6 +230964,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -230563,6 +231022,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -230636,6 +231096,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -230691,7 +231152,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -230704,55 +231164,15 @@ 0, 0, 0, - 2, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science", - "sourceId": "MZ3RLT", - "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?", - "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Impact" - ], - "tags": [ - "Permissionless", - "Use Cases", - "DeSci", - "impact", - "DeSci", - "Permissionless", - "Use Cases" - ], - "language": "en", - "speakers": [ - "paul-kohlhaas" - ], - "eventId": "devcon-7", - "slot_start": 1731658800000, - "slot_end": 1731659400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -230974,8 +231394,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -230987,6 +231409,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "designing-an-end-to-end-solution-for-based-preconfirmations", + "sourceId": "CRWBCC", + "title": "Designing an End to End Solution for Based Preconfirmations", + "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Preconfirmations", + "Based Rollups", + "Based Sequencing" + ], + "tags": [ + "Layer 2s", + "Rollups", + "User Experience", + "sequencer", + "based", + "Layer 2s", + "Rollups", + "User Experience" + ], + "language": "en", + "speakers": [ + "anshu-jalan", + "ahmad-bitar" + ], + "eventId": "devcon-7", + "slot_start": 1731655800000, + "slot_end": 1731661200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8" + }, + "vector": [ 0, 0, 0, @@ -230994,6 +231458,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -231005,7 +231470,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -231248,6 +231712,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -231564,7 +232030,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -231619,7 +232084,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -231677,7 +232141,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -231747,11 +232210,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -231773,8 +232236,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -231795,6 +232260,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -231841,6 +232307,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -232049,10 +232516,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -232064,48 +232529,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "designing-an-end-to-end-solution-for-based-preconfirmations", - "sourceId": "CRWBCC", - "title": "Designing an End to End Solution for Based Preconfirmations", - "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Preconfirmations", - "Based Rollups", - "Based Sequencing" - ], - "tags": [ - "Layer 2s", - "Rollups", - "User Experience", - "sequencer", - "based", - "Layer 2s", - "Rollups", - "User Experience" - ], - "language": "en", - "speakers": [ - "anshu-jalan", - "ahmad-bitar" - ], - "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731661200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8" - }, - "vector": [ 0, 0, 0, @@ -232113,7 +232536,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -232334,9 +232756,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -232349,6 +232773,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "designing-and-launching-a-retroround-incentivize-what-matters", + "sourceId": "39AVKD", + "title": "Designing and launching a RetroRound - Incentivize what matters", + "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.", + "track": "Coordination", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Emerging markets", + "Grant Program Design", + "" + ], + "tags": [ + "RPGF", + "Quadratic Voting", + "Public good", + "Design", + "Mechanism design", + "program", + "grants", + "Mechanism design", + "Public good", + "Quadratic Voting", + "RPGF" + ], + "language": "en", + "speakers": [ + "launamu", + "sejal-rekhan" + ], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731576600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4" + }, + "vector": [ 0, 0, 0, @@ -232360,14 +232829,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -232613,6 +233081,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -232861,7 +233331,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -232887,10 +233356,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -232911,7 +233378,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -232958,7 +233424,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -233099,9 +233564,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, 0, 0, 0, @@ -233203,6 +233670,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -233236,6 +233704,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -233303,6 +233772,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -233358,6 +233828,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -233407,11 +233879,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -233424,51 +233894,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "designing-and-launching-a-retroround-incentivize-what-matters", - "sourceId": "39AVKD", - "title": "Designing and launching a RetroRound - Incentivize what matters", - "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.", - "track": "Coordination", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Emerging markets", - "Grant Program Design", - "" - ], - "tags": [ - "RPGF", - "Quadratic Voting", - "Public good", - "Design", - "Mechanism design", - "program", - "grants", - "Mechanism design", - "Public good", - "Quadratic Voting", - "RPGF" - ], - "language": "en", - "speakers": [ - "launamu", - "sejal-rekhan" - ], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4" - }, - "vector": [ 0, 0, 0, @@ -233480,7 +233905,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -233701,12 +234125,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -233714,8 +234140,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "designing-conditional-markets-and-futarchy", + "sourceId": "EWJNVJ", + "title": "Designing Conditional Markets and Futarchy", + "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Prediction", + "markets" + ], + "tags": [ + "market", + "prediction", + "DAO", + "Futarchy", + "Public good" + ], + "language": "en", + "speakers": [ + "kaseth", + "robin-hanson" + ], + "eventId": "devcon-7", + "slot_start": 1731487800000, + "slot_end": 1731489600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -233731,8 +234196,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -233980,6 +234443,18 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -234211,11 +234686,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -234317,7 +234790,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234351,7 +234823,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234419,7 +234890,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234475,6 +234945,18 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 2, 0, @@ -234540,6 +235022,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -234547,6 +235030,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -234772,14 +235256,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -234787,47 +235269,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "designing-conditional-markets-and-futarchy", - "sourceId": "EWJNVJ", - "title": "Designing Conditional Markets and Futarchy", - "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Prediction", - "markets" - ], - "tags": [ - "market", - "prediction", - "DAO", - "Futarchy", - "Public good" - ], - "language": "en", - "speakers": [ - "kaseth", - "robin-hanson" - ], - "eventId": "devcon-7", - "slot_start": 1731487800000, - "slot_end": 1731489600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -235040,6 +235483,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235048,6 +235492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235055,12 +235500,42 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "type": "Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "skylar-weaver", + "nathan-sexer" + ], + "eventId": "devcon-7", + "slot_start": 1731385800000, + "slot_end": 1731388500000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -235089,8 +235564,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -235241,6 +235714,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -235322,6 +235796,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -235597,11 +236073,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -235665,7 +236138,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -235673,7 +236145,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -236126,7 +236597,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -236135,7 +236605,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -236143,42 +236612,12 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "type": "Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "skylar-weaver", - "nathan-sexer" - ], - "eventId": "devcon-7", - "slot_start": 1731385800000, - "slot_end": 1731388500000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -236356,7 +236795,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -236397,7 +236835,10 @@ 0, 0, 0, + 2, + 0, 0, + 2, 0, 0, 0, @@ -236410,6 +236851,47 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Folding schemes", + "IVC", + "Nova" + ], + "tags": [ + "Libraries", + "Zero-Knowledge", + "Cryptography", + "nova", + "Cryptography", + "Libraries", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "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, 0, 0, @@ -236420,6 +236902,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -236438,7 +236921,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -236459,6 +236941,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -236677,6 +237160,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -237162,6 +237646,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -237417,6 +237904,21 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -237474,10 +237976,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -237490,47 +237990,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Folding schemes", - "IVC", - "Nova" - ], - "tags": [ - "Libraries", - "Zero-Knowledge", - "Cryptography", - "nova", - "Cryptography", - "Libraries", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "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, 0, 0, @@ -237541,7 +238000,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -237579,18 +238037,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -237751,9 +238197,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -237766,6 +238214,38 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "digital-pheromones-mpc-for-human-connection-and-coordination", + "sourceId": "LMCG3V", + "title": "Digital pheromones: MPC for human connection & coordination", + "description": "Recent MPC research from Cursive and PSE enables a new concept called \"digital pheromones\": the ability to produce lightweight, privacy-preserving signals that people can use to coordinate safely and efficiently.\r\n\r\nThe primary result we will cover is Trinity, a new 2PC scheme with nearly ideal UX/DevX, built on the trio of PLONK, Garbled Circuits, and KZG Witness Encryption. We will do a live demo with attendees and explore what a future filled with digital pheromones will enable!", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "MPC", + "Privacy", + "Use cases of cryptography" + ], + "language": "en", + "speakers": [ + "vivek-bhupatiraju" + ], + "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" + }, + "vector": [ 0, 0, 0, @@ -237776,6 +238256,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -237798,7 +238279,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -238035,6 +238515,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -238281,9 +238762,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -238600,6 +239078,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -238627,6 +239106,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -238832,55 +239312,12 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "digital-pheromones-mpc-for-human-connection-and-coordination", - "sourceId": "LMCG3V", - "title": "Digital pheromones: MPC for human connection & coordination", - "description": "Recent MPC research from Cursive and PSE enables a new concept called \"digital pheromones\": the ability to produce lightweight, privacy-preserving signals that people can use to coordinate safely and efficiently.\r\n\r\nThe primary result we will cover is Trinity, a new 2PC scheme with nearly ideal UX/DevX, built on the trio of PLONK, Garbled Circuits, and KZG Witness Encryption. We will do a live demo with attendees and explore what a future filled with digital pheromones will enable!", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "MPC", - "Privacy", - "Use cases of cryptography" - ], - "language": "en", - "speakers": [ - "vivek-bhupatiraju" - ], - "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" - }, - "vector": [ 0, 0, 0, @@ -238891,7 +239328,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -239115,10 +239551,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -239130,9 +239568,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "discovery-the-tool-at-the-core-of-l2beat", + "sourceId": "G9ESC7", + "title": "Discovery - the tool at the core of L2BEAT", + "description": "Hands on workshop about how to use an L2BEAT tool called discovery for mapping, researching and monitoring all the contracts involved in a project. We'll start by introducing the problem that discovery tries to solve and after that we'll get into trying to understand the architecture of a real world project by using the avenues this tool gives us. After this session the participant should feel empowered to use discovery to deepen his knowledge about all on-chain deployments.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developper", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Holistic monitoring", + "Architecture research" + ], + "tags": [ + "Architecture", + "Tooling", + "DevEx", + "Event monitoring", + "research", + "DevEx", + "Event monitoring", + "Tooling" + ], + "language": "en", + "speakers": [ + "mateusz-radomski" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731645900000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1T24SoFUkubwO-ppCiYWJoisNwayKtozmAgEJYNPvVho" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -239149,7 +239628,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -239400,6 +239878,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -239648,7 +240127,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -239709,7 +240187,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -239737,7 +240214,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -239896,6 +240372,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -239904,6 +240381,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -239935,6 +240413,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240125,6 +240604,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240141,6 +240621,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240182,12 +240663,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -240199,50 +240678,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "discovery-the-tool-at-the-core-of-l2beat", - "sourceId": "G9ESC7", - "title": "Discovery - the tool at the core of L2BEAT", - "description": "Hands on workshop about how to use an L2BEAT tool called discovery for mapping, researching and monitoring all the contracts involved in a project. We'll start by introducing the problem that discovery tries to solve and after that we'll get into trying to understand the architecture of a real world project by using the avenues this tool gives us. After this session the participant should feel empowered to use discovery to deepen his knowledge about all on-chain deployments.", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Developper", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Holistic monitoring", - "Architecture research" - ], - "tags": [ - "Architecture", - "Tooling", - "DevEx", - "Event monitoring", - "research", - "DevEx", - "Event monitoring", - "Tooling" - ], - "language": "en", - "speakers": [ - "mateusz-radomski" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731645900000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1T24SoFUkubwO-ppCiYWJoisNwayKtozmAgEJYNPvVho" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -240475,6 +240913,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -240486,10 +240925,37 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 0 + ] + }, + { + "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", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731668400000, + "slot_end": 1731675600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E" + }, + "vector": [ 0, 0, 0, @@ -240499,6 +240965,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -240508,7 +240975,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -240999,7 +241465,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241008,7 +241473,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241040,7 +241504,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241231,7 +241694,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241248,7 +241710,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241540,7 +242001,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -241552,37 +242012,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 0 - ] - }, - { - "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", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731668400000, - "slot_end": 1731675600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E" - }, - "vector": [ 0, 0, 0, @@ -241592,7 +242025,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -241830,8 +242262,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -241844,6 +242278,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "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", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731567600000, + "slot_end": 1731571200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI" + }, + "vector": [ 0, 0, 0, @@ -241853,6 +242313,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -242885,10 +243346,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -242901,32 +243360,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "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", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731571200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI" - }, - "vector": [ 0, 0, 0, @@ -242936,7 +243369,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -243178,8 +243610,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -243192,6 +243626,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "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", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731639600000, + "slot_end": 1731643200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -244229,10 +244703,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -244245,32 +244717,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "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", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731643200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4" - }, - "vector": [ 0, 0, 0, @@ -244280,7 +244726,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -244513,8 +244958,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -244527,6 +244974,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "dj-mayu", + "sourceId": "XV779L", + "title": "DJ MAYU", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731650400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk" + }, + "vector": [ 0, 0, 0, @@ -244536,6 +245009,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -245573,10 +246047,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -245589,32 +246061,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "dj-mayu", - "sourceId": "XV779L", - "title": "DJ MAYU", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731650400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk" - }, - "vector": [ 0, 0, 0, @@ -245624,7 +246070,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -245861,6 +246306,61 @@ 0, 0, 0, + 2, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "djing-pino7", + "sourceId": "SPWJHX", + "title": "DJing - pino7", + "description": "I am a builder and a volunteer in Devcon SEA. Back in the days I've decided that I wanted to become awesome, and here I am in my journey. I am UX/UI Designer and I am becoming a React Developer. I have always being passionate about music. And there's always space for it during my life journey. I love communities, people, organizing events and playing some good music.", + "track": "Entertainment", + "type": "Music", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "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, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, 0, 0, 0, @@ -246121,6 +246621,22 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -246917,10 +247433,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -246933,34 +247447,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "djing-pino7", - "sourceId": "SPWJHX", - "title": "DJing - pino7", - "description": "I am a builder and a volunteer in Devcon SEA. Back in the days I've decided that I wanted to become awesome, and here I am in my journey. I am UX/UI Designer and I am becoming a React Developer. I have always being passionate about music. And there's always space for it during my life journey. I love communities, people, organizing events and playing some good music.", - "track": "Entertainment", - "type": "Music", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "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, 0, 0, @@ -246970,7 +247456,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -247170,6 +247655,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -247178,6 +247664,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -247185,6 +247672,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "do-you-really-know-your-web3-users", + "sourceId": "YRDFDY", + "title": "Do you really know your web3 users?", + "description": "Product discovery is to understand users' problems and using that knowledge to build a product. In the world of Web3, where anonymity & privacy prevail, how can teams identify user segments & collect relevant data to understand behaviours behind accounts? As we aim to onboard the next billion web3 users, how should we approach activation & growth, considering best practices and emerging trends? This panel will explore strategies for effective product discovery in a privacy-centric ecosystem.", + "track": "Usability", + "type": "Panel", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Product Management", + "Strategy", + "Product Discovery" + ], + "tags": [ + "Product-market fit", + "User Experience", + "UI/UX", + "User Research", + "product", + "discovery", + "Product-market fit", + "UI/UX", + "User Experience", + "User Research" + ], + "language": "en", + "speakers": [ + "rahul-rumalla", + "alice-chaverot", + "austin-keeble", + "romina-bungert" + ], + "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" + }, + "vector": [ 0, 0, 0, @@ -247193,6 +247726,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -247231,7 +247765,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -247457,6 +247990,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -247940,6 +248477,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -247981,6 +248519,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -248008,6 +248548,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -248191,6 +248732,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -248262,84 +248805,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "do-you-really-know-your-web3-users", - "sourceId": "YRDFDY", - "title": "Do you really know your web3 users?", - "description": "Product discovery is to understand users' problems and using that knowledge to build a product. In the world of Web3, where anonymity & privacy prevail, how can teams identify user segments & collect relevant data to understand behaviours behind accounts? As we aim to onboard the next billion web3 users, how should we approach activation & growth, considering best practices and emerging trends? This panel will explore strategies for effective product discovery in a privacy-centric ecosystem.", - "track": "Usability", - "type": "Panel", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Product Management", - "Strategy", - "Product Discovery" - ], - "tags": [ - "Product-market fit", - "User Experience", - "UI/UX", - "User Research", - "product", - "discovery", - "Product-market fit", - "UI/UX", - "User Experience", - "User Research" - ], - "language": "en", - "speakers": [ - "rahul-rumalla", - "alice-chaverot", - "austin-keeble", - "romina-bungert" - ], - "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" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -248560,11 +249025,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -248573,8 +249040,44 @@ 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", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Intents", + "MEV", + "PBS", + "Redistribution" + ], + "tags": [ + "redistribution" + ], + "language": "en", + "speakers": [ + "felix-leupold" + ], + "eventId": "devcon-7", + "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, 0, @@ -248596,10 +249099,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -248852,6 +249351,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -249080,7 +249580,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -249122,8 +249621,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -249151,7 +249648,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -249335,8 +249831,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -249597,6 +250091,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -249628,59 +250123,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 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", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Intents", - "MEV", - "PBS", - "Redistribution" - ], - "tags": [ - "redistribution" - ], - "language": "en", - "speakers": [ - "felix-leupold" - ], - "eventId": "devcon-7", - "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, 0, @@ -249938,9 +250380,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -249953,6 +250397,45 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": true, + "keywords": [ + "user safety", + "developer safety", + "phishing" + ], + "tags": [ + "Tooling", + "Security", + "phishing", + "Security", + "Tooling" + ], + "language": "en", + "speakers": [ + "tincho", + "matta-the-red-guild" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731495600000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk" + }, + "vector": [ 6, 0, 0, @@ -250230,6 +250713,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -250690,11 +251175,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -250715,6 +251200,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -250967,6 +251453,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -250979,11 +251466,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -250996,46 +251481,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": true, - "keywords": [ - "user safety", - "developer safety", - "phishing" - ], - "tags": [ - "Tooling", - "Security", - "phishing", - "Security", - "Tooling" - ], - "language": "en", - "speakers": [ - "tincho", - "matta-the-red-guild" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731495600000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk" - }, - "vector": [ - 6, 0, 0, 0, @@ -251296,11 +251741,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -251311,16 +251758,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "double-entry-point-issues-from-breaking-compound-to-uniswap-v4", + "sourceId": "N9ZSQW", + "title": "Double entry point issues - From breaking Compound to Uniswap v4", + "description": "A short explanation of a critical-severity vulnerability we found in the Uniswap V4 core contracts that would have caused a ~$15M loss in Uniswap's pools. The goal is to explain the risks of double entry points, from the $30M+ TUSD issue in Compound to the Uniswap V4-specific case where protocols use native tokens and operate on chains where the native token has a corresponding ERC-20 token, and how to prevent them.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Contest" + ], + "tags": [ + "Security", + "Bug", + "Bounties", + "contest", + "Architecture", + "Auditing", + "Bug", + "Security" + ], + "language": "en", + "speakers": [ + "jota-carpanelli" + ], + "eventId": "devcon-7", + "slot_start": 1731657000000, + "slot_end": 1731657600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0" + }, + "vector": [ 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -251599,6 +252076,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -251774,7 +252252,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -251795,7 +252272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -252048,7 +252524,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -252065,6 +252540,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -252126,6 +252602,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252215,6 +252692,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252321,6 +252799,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252337,12 +252816,12 @@ 0, 0, 2, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -252353,46 +252832,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "double-entry-point-issues-from-breaking-compound-to-uniswap-v4", - "sourceId": "N9ZSQW", - "title": "Double entry point issues - From breaking Compound to Uniswap v4", - "description": "A short explanation of a critical-severity vulnerability we found in the Uniswap V4 core contracts that would have caused a ~$15M loss in Uniswap's pools. The goal is to explain the risks of double entry points, from the $30M+ TUSD issue in Compound to the Uniswap V4-specific case where protocols use native tokens and operate on chains where the native token has a corresponding ERC-20 token, and how to prevent them.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Contest" - ], - "tags": [ - "Security", - "Bug", - "Bounties", - "contest", - "Architecture", - "Auditing", - "Bug", - "Security" - ], - "language": "en", - "speakers": [ - "jota-carpanelli" - ], - "eventId": "devcon-7", - "slot_start": 1731657000000, - "slot_end": 1731657600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0" - }, - "vector": [ - 6, 0, 0, 0, @@ -252663,14 +253102,15 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, - 6, 0, 0, 0, @@ -252679,12 +253119,51 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "mainstream" + ], + "tags": [ + "Quadratic Voting", + "Public good", + "Local Impact", + "UI/UX", + "mainstream", + "Public good", + "UI/UX" + ], + "language": "en", + "speakers": [ + "kevin-owocki" + ], + "eventId": "devcon-7", + "slot_start": 1731581400000, + "slot_end": 1731582000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -252958,6 +253437,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -253131,7 +253611,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -253193,7 +253672,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253283,7 +253761,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253390,7 +253867,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253406,8 +253882,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -253485,6 +253959,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -253534,6 +254009,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -253635,6 +254111,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -253668,6 +254145,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -253693,7 +254173,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -253710,51 +254189,12 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "mainstream" - ], - "tags": [ - "Quadratic Voting", - "Public good", - "Local Impact", - "UI/UX", - "mainstream", - "Public good", - "UI/UX" - ], - "language": "en", - "speakers": [ - "kevin-owocki" - ], - "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -254024,13 +254464,14 @@ 0, 0, 0, + 2, 0, 0, 0, - 6, 0, 0, 0, + 2, 0, 0, 0, @@ -254038,12 +254479,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ebay-and-web3-powered-digital-product-passports-and-what-this-could-mean-for-the-future-of-commerce", + "sourceId": "DWMA3P", + "title": "eBay & web3 powered Digital Product Passports and what this could mean for the future of commerce?", + "description": "eBay is embracing web3 technologies to fulfil the vision of a truly connected product world. Digital Product Passports (DPPs) underpin this movement with a real world application of public blockchain technologies, tokenised products, attestation based technologies and selective disclosure schemes as the technology of choice.\r\n\r\nI will explore what this could mean for one of the world of ecommerce, why brands are embracing this movement and whats in it for the consumer.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "digital-product-passports", + "DPPs", + "luxury" + ], + "tags": [ + "Digital Sovereignty", + "Use Cases", + "Regulation", + "luxury", + "Digital Sovereignty", + "Regulation", + "Use Cases" + ], + "language": "en", + "speakers": [ + "james-morgan" + ], + "eventId": "devcon-7", + "slot_start": 1731567600000, + "slot_end": 1731568200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -254318,6 +254800,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -254546,7 +255030,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -254596,7 +255079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -254698,7 +255180,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -254732,7 +255213,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -254764,7 +255244,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -254833,6 +255312,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -254861,6 +255341,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -254888,6 +255369,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -255051,7 +255534,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255066,53 +255548,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ebay-and-web3-powered-digital-product-passports-and-what-this-could-mean-for-the-future-of-commerce", - "sourceId": "DWMA3P", - "title": "eBay & web3 powered Digital Product Passports and what this could mean for the future of commerce?", - "description": "eBay is embracing web3 technologies to fulfil the vision of a truly connected product world. Digital Product Passports (DPPs) underpin this movement with a real world application of public blockchain technologies, tokenised products, attestation based technologies and selective disclosure schemes as the technology of choice.\r\n\r\nI will explore what this could mean for one of the world of ecommerce, why brands are embracing this movement and whats in it for the consumer.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "digital-product-passports", - "DPPs", - "luxury" - ], - "tags": [ - "Digital Sovereignty", - "Use Cases", - "Regulation", - "luxury", - "Digital Sovereignty", - "Regulation", - "Use Cases" - ], - "language": "en", - "speakers": [ - "james-morgan" - ], - "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731568200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -255379,6 +255820,78 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first", + "sourceId": "EY3HL9", + "title": "Ecosystem Development Best Practices, and why we need to start with builders first", + "description": "Given the myriad of chains out there, it is increasingly crucial for L2s to solidify their ecosystem building playbook and constantly refine it to win over (and more importantly, retain) users and builders. As an ecosystem builder in SEA (Thailand) who has worked with over 10 ecosystems including other L1s, on local, regional and global initiatives, I am excited to share the ins and outs of ecosystem building from a neutral perspective.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", + "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" + ], + "duration": 407, + "language": "en", + "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896", + "sources_youtubeId": "xqs8trszoOY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331cf83a168eb5353a19d3.vtt", + "transcript_text": " Hi, good afternoon, guys. So my name is Ngan. I'm the co-founder of Symmetry. I'm also a fellow Thai here. So it's a pleasure for us to welcome you to my home country and my hometown, which is Bangkok. So really excited to be here. So yeah, straight into my talk. So as you can see from the talk title, it's about ecosystem development. So what I do at Symmetry is basically we help change on what more builders and users from Thailand. So I figured this would be a good topic to touch on given DEF CON so what exactly is ecosystem building so ecosystem building is basically a to the marketplace right so side marketplace so when you're building chains you need both barriers and users and you did both at we strategic timings a chain cannot function with one or another", + "eventId": "devcon-7", + "slot_start": 1731402000000, + "slot_end": 1731402600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw", + "resources_slides": null, + "speakers": [ + "nine-arnakorn" + ] + }, + "vector": [ 0, 0, 0, @@ -255661,6 +256174,39 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -255895,7 +256441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255924,7 +256469,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -255952,7 +256496,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -256158,6 +256701,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -256260,6 +256809,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -256363,6 +256914,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -256409,13 +256962,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -256424,57 +256975,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first", - "sourceId": "EY3HL9", - "title": "Ecosystem Development Best Practices, and why we need to start with builders first", - "description": "Given the myriad of chains out there, it is increasingly crucial for L2s to solidify their ecosystem building playbook and constantly refine it to win over (and more importantly, retain) users and builders. As an ecosystem builder in SEA (Thailand) who has worked with over 10 ecosystems including other L1s, on local, regional and global initiatives, I am excited to share the ins and outs of ecosystem building from a neutral perspective.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Business", - "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" - ], - "duration": 407, - "language": "en", - "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896", - "sources_youtubeId": "xqs8trszoOY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331cf83a168eb5353a19d3.vtt", - "transcript_text": " Hi, good afternoon, guys. So my name is Ngan. I'm the co-founder of Symmetry. I'm also a fellow Thai here. So it's a pleasure for us to welcome you to my home country and my hometown, which is Bangkok. So really excited to be here. So yeah, straight into my talk. So as you can see from the talk title, it's about ecosystem development. So what I do at Symmetry is basically we help change on what more builders and users from Thailand. So I figured this would be a good topic to touch on given DEF CON so what exactly is ecosystem building so ecosystem building is basically a to the marketplace right so side marketplace so when you're building chains you need both barriers and users and you did both at we strategic timings a chain cannot function with one or another", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731402600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw", - "resources_slides": null, - "speakers": [ - "nine-arnakorn" - ] - }, - "vector": [ 0, 0, 0, @@ -256482,7 +256982,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -256700,10 +257199,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -256713,12 +257214,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eea-and-the-institutional-infinity-garden", + "sourceId": "JQBXXD", + "title": "EEA and the Institutional Infinity Garden", + "description": "This talk would be to give an overview on the latest from the Enterprise Ethereum Alliance, how the year has progressed in enterprise and how EEA seeks to support and guide institutions to participate in Ethereum's Infinity Garden.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Business", + "Enterprise", + "Instituional" + ], + "tags": [ + "Coordination", + "Vision", + "Use Cases", + "institutional", + "Coordination", + "Use Cases", + "Vision" + ], + "language": "en", + "speakers": [ + "karen-scarbrough" + ], + "eventId": "devcon-7", + "slot_start": 1731480000000, + "slot_end": 1731480600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1f1uiHRqQIfhY0F3DmSPJ-wpu3lCdP00YCID-a2-UblQ" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -256756,7 +257298,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -256996,6 +257537,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -257245,7 +257787,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257280,7 +257821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257388,7 +257928,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257493,8 +258032,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -257539,6 +258076,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257614,6 +258152,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257694,6 +258233,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257738,6 +258278,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257778,69 +258319,22 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "eea-and-the-institutional-infinity-garden", - "sourceId": "JQBXXD", - "title": "EEA and the Institutional Infinity Garden", - "description": "This talk would be to give an overview on the latest from the Enterprise Ethereum Alliance, how the year has progressed in enterprise and how EEA seeks to support and guide institutions to participate in Ethereum's Infinity Garden.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Business", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Business", - "Enterprise", - "Instituional" - ], - "tags": [ - "Coordination", - "Vision", - "Use Cases", - "institutional", - "Coordination", - "Use Cases", - "Vision" - ], - "language": "en", - "speakers": [ - "karen-scarbrough" - ], - "eventId": "devcon-7", - "slot_start": 1731480000000, - "slot_end": 1731480600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1f1uiHRqQIfhY0F3DmSPJ-wpu3lCdP00YCID-a2-UblQ" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -258067,10 +258561,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -258080,6 +258576,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "efficient-non-native-snark-recursion-using-bivariate-polynomial-testing", + "sourceId": "E8KYKE", + "title": "Efficient non-native SNARK recursion using bivariate polynomial testing", + "description": "Efficient SNARK recursion requires switching between pairing friendly elliptic curves. In most optimal approaches these curves would construct a cycle, but there are no such known cycles. Instead, we use non-native arithmetic to brute force the pairing computation at the cycle cut-off.\r\nWe describe an approach for combining direct field extension with polynomial-based non-native arithmetic. This reduces pairing computation to bivariate polynomial identity testing using Schwartz-Zippel lemma.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Pairing", + "based", + "ZK" + ], + "tags": [ + "ZKP", + "Cryptography", + "SNARK", + "zk", + "based", + "pairing", + "Cryptography", + "SNARK", + "ZKP" + ], + "language": "en", + "speakers": [ + "ivo-kubjas" + ], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1uBrjsIa4svOJ9BePcS4YgEcFXFjVxeeeS9RBVSKBwzw" + }, + "vector": [ 0, 0, 0, @@ -258090,6 +258628,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -258115,7 +258654,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -258364,6 +258902,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -258651,7 +259190,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258727,7 +259265,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258808,7 +259345,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258838,6 +259374,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -258853,7 +259390,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -258870,6 +259406,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -258899,6 +259436,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -259105,6 +259643,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -259136,12 +259677,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -259151,48 +259690,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "efficient-non-native-snark-recursion-using-bivariate-polynomial-testing", - "sourceId": "E8KYKE", - "title": "Efficient non-native SNARK recursion using bivariate polynomial testing", - "description": "Efficient SNARK recursion requires switching between pairing friendly elliptic curves. In most optimal approaches these curves would construct a cycle, but there are no such known cycles. Instead, we use non-native arithmetic to brute force the pairing computation at the cycle cut-off.\r\nWe describe an approach for combining direct field extension with polynomial-based non-native arithmetic. This reduces pairing computation to bivariate polynomial identity testing using Schwartz-Zippel lemma.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Pairing", - "based", - "ZK" - ], - "tags": [ - "ZKP", - "Cryptography", - "SNARK", - "zk", - "based", - "pairing", - "Cryptography", - "SNARK", - "ZKP" - ], - "language": "en", - "speakers": [ - "ivo-kubjas" - ], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1uBrjsIa4svOJ9BePcS4YgEcFXFjVxeeeS9RBVSKBwzw" - }, - "vector": [ 0, 0, 0, @@ -259203,7 +259700,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -259427,9 +259923,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -259442,10 +259940,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eip-7251-maximum-effective-balance-overview", + "sourceId": "BBFNLG", + "title": "EIP-7251 - Maximum effective balance overview", + "description": "An overview of the maximum effective balance change coming in Electra.\r\nAt a high level, other considerations that were required to allow the maximum effective balance increase in Electra, and ensure that it delivers value.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "tags": [ + "Core Protocol", + "Staking", + "Pectra", + "Core Protocol", + "Staking" + ], + "keywords": [ + "Pectra" + ], + "duration": 1218, + "language": "en", + "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc", + "sources_youtubeId": "EwW6dNi9VCY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733027280d989c5b7bd3263.vtt", + "transcript_text": " Hi everyone. Jeez, these lights are bright. I'm here today to talk to you about increasing the maximum effective balance, EIP 7251. It's less of a technical talk than the previous one, because I think there's a few things we probably need to go over.", + "eventId": "devcon-7", + "slot_start": 1731394800000, + "slot_end": 1731396600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Q5srMGhMm8grwI_O0CFKN_QN1QRx24-AxIwgbDha6U0", + "resources_slides": null, + "speakers": [ + "paul-harris" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -259476,7 +260020,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -259727,6 +260270,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -259945,7 +260489,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -259977,7 +260520,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -260007,7 +260549,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -260206,6 +260747,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260214,9 +260756,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -260318,6 +260857,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260473,6 +261013,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260494,11 +261035,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -260510,57 +261049,10 @@ 0, 0, 0, - 0, - 0 - ] - }, - { - "session": { - "id": "eip-7251-maximum-effective-balance-overview", - "sourceId": "BBFNLG", - "title": "EIP-7251 - Maximum effective balance overview", - "description": "An overview of the maximum effective balance change coming in Electra.\r\nAt a high level, other considerations that were required to allow the maximum effective balance increase in Electra, and ensure that it delivers value.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "tags": [ - "Core Protocol", - "Staking", - "Pectra", - "Core Protocol", - "Staking" - ], - "keywords": [ - "Pectra" - ], - "duration": 1218, - "language": "en", - "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc", - "sources_youtubeId": "EwW6dNi9VCY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733027280d989c5b7bd3263.vtt", - "transcript_text": " Hi everyone. Jeez, these lights are bright. I'm here today to talk to you about increasing the maximum effective balance, EIP 7251. It's less of a technical talk than the previous one, because I think there's a few things we probably need to go over.", - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731396600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Q5srMGhMm8grwI_O0CFKN_QN1QRx24-AxIwgbDha6U0", - "resources_slides": null, - "speakers": [ - "paul-harris" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -260798,6 +261290,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260807,16 +261300,63 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eip-7702-a-technical-deep-dive", + "sourceId": "NNNPLC", + "title": "EIP-7702: a technical deep dive", + "description": "We'll discuss some of the design goals that lead to EIP-7702, how it works, and what will be possible for users after the Pectra network upgrade.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Core Protocol", + "Account Abstraction", + "eip", + "Account Abstraction", + "Core Protocol" + ], + "keywords": [ + "EIP" + ], + "duration": 1299, + "language": "en", + "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", + "sources_youtubeId": "_k5fKlKBWV4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731393000000, + "slot_end": 1731394800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/15huammnvrT8ljoiAi9Bnn4jcV_r6L0sm3_gBK-LqQ-4", + "resources_slides": null, + "speakers": [ + "lightclient" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -260840,7 +261380,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -260982,6 +261521,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -261314,7 +261854,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -261424,7 +261963,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -261576,11 +262114,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -261608,6 +262146,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -261842,6 +262381,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -261857,7 +262397,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -261867,63 +262406,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eip-7702-a-technical-deep-dive", - "sourceId": "NNNPLC", - "title": "EIP-7702: a technical deep dive", - "description": "We'll discuss some of the design goals that lead to EIP-7702, how it works, and what will be possible for users after the Pectra network upgrade.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Core Protocol", - "Account Abstraction", - "eip", - "Account Abstraction", - "Core Protocol" - ], - "keywords": [ - "EIP" - ], - "duration": 1299, - "language": "en", - "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", - "sources_youtubeId": "_k5fKlKBWV4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731394800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/15huammnvrT8ljoiAi9Bnn4jcV_r6L0sm3_gBK-LqQ-4", - "resources_slides": null, - "speakers": [ - "lightclient" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -262087,7 +262579,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -262169,6 +262660,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -262181,6 +262674,43 @@ 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, + "keywords": [ + "ePBS", + "EIP-7732" + ], + "tags": [ + "Censorship Resistance", + "Consensus", + "Core Protocol", + "PBS" + ], + "language": "en", + "speakers": [ + "kira", + "caleb" + ], + "eventId": "devcon-7", + "slot_start": 1731477600000, + "slot_end": 1731478500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM" + }, + "vector": [ 0, 0, 0, @@ -262196,6 +262726,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -262340,6 +262871,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -262465,6 +262997,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -262677,7 +263210,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262709,7 +263241,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262928,6 +263459,24 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -263053,6 +263602,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -263223,8 +263773,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -263237,43 +263785,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eip-7732-enshrined-proposer-builder-separation", - "sourceId": "TKBF9R", - "title": "[EIP-7732] enshrined Proposer Builder Separation", - "description": "ePBS implementation in Prysm and Nimbus, fundamentally aimed at solving about solving trust issues. We're gonna discuss the block-auction, slot-auction and the approach proposed by Francesco during the cohort. Some technical challenges and problems that we came across like separating EL and CL block, PTC committee etc.", - "track": "[CLS] EPF Day", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ePBS", - "EIP-7732" - ], - "tags": [ - "Censorship Resistance", - "Consensus", - "Core Protocol", - "PBS" - ], - "language": "en", - "speakers": [ - "kira", - "caleb" - ], - "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731478500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM" - }, - "vector": [ 0, 0, 0, @@ -263289,7 +263800,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -263433,7 +263943,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -263507,9 +264016,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -263522,10 +264033,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, @@ -263559,7 +264125,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -263809,6 +264374,13 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -264018,7 +264590,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -264032,7 +264603,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264052,7 +264622,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264161,7 +264730,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264281,6 +264849,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -264357,6 +264926,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -264415,6 +264985,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -264545,6 +265116,10 @@ 0, 0, 0, + 2, + 2, + 2, + 2, 0, 0, 0, @@ -264575,11 +265150,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -264592,65 +265165,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, @@ -264874,6 +265392,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -264882,6 +265401,49 @@ 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, @@ -264891,6 +265453,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -264932,8 +265495,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -265172,6 +265733,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -265404,7 +265968,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265481,7 +266044,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265540,7 +266102,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265671,10 +266232,6 @@ 0, 0, 0, - 2, - 2, - 2, - 2, 0, 0, 0, @@ -265738,6 +266295,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -265916,6 +266477,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -265947,7 +266512,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265956,7 +266520,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -265964,41 +266527,6 @@ 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, @@ -266008,7 +266536,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -266224,12 +266751,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -266237,6 +266766,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, @@ -266247,6 +266825,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -266287,7 +266866,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -266527,6 +267105,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -266846,7 +267425,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266993,6 +267571,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267028,7 +267607,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267055,6 +267633,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -267261,6 +267840,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -267269,6 +267849,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -267302,14 +267884,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -267317,55 +267897,6 @@ 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, @@ -267376,7 +267907,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -267590,9 +268120,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -267605,6 +268137,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, @@ -267614,6 +268172,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267655,7 +268214,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -268118,7 +268676,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -268180,7 +268737,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -268387,7 +268943,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -268396,8 +268951,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -268667,11 +269220,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -268684,32 +269235,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, @@ -268719,7 +269244,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -268946,6 +269470,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -268954,15 +269479,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, @@ -269249,6 +269814,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -269719,6 +270285,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -269942,6 +270509,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -269985,11 +270553,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -270013,7 +270583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270022,55 +270591,11 @@ 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, @@ -270303,9 +270828,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -270318,8 +270845,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, @@ -270356,7 +270926,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -270610,6 +271179,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -270824,7 +271394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -271048,7 +271617,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -271064,6 +271632,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -271092,13 +271661,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -271129,6 +271696,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -271145,6 +271713,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -271263,6 +271832,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -271354,6 +271924,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -271367,11 +271939,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -271384,51 +271954,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, @@ -271665,10 +272192,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -271680,6 +272209,49 @@ 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, + "keywords": [ + "Ethereum Node", + "Tooling", + "Network Access" + ], + "tags": [ + "Staking", + "Best Practices", + "Accessibility", + "network", + "access", + "Accessibility", + "Best Practices", + "Staking" + ], + "language": "en", + "speakers": [ + "stefan-kobrc", + "stereum-team", + "david-muhlbacher" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8" + }, + "vector": [ 0, 0, 0, @@ -271688,6 +272260,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -271717,7 +272290,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -271973,6 +272545,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -272167,7 +272742,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -272231,7 +272805,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272248,7 +272821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272367,7 +272939,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272455,12 +273026,11 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -272485,6 +273055,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -272512,6 +273083,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -272552,6 +273124,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -272718,6 +273291,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -272727,12 +273301,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -272744,49 +273316,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, - "keywords": [ - "Ethereum Node", - "Tooling", - "Network Access" - ], - "tags": [ - "Staking", - "Best Practices", - "Accessibility", - "network", - "access", - "Accessibility", - "Best Practices", - "Staking" - ], - "language": "en", - "speakers": [ - "stefan-kobrc", - "stereum-team", - "david-muhlbacher" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8" - }, - "vector": [ 0, 0, 0, @@ -272795,7 +273324,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -273031,6 +273559,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273038,13 +273567,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": 1731579000000, + "slot_end": 1731579600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -273079,9 +273644,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -273342,6 +273904,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -273557,7 +274120,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273586,7 +274148,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273614,7 +274175,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273655,7 +274215,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273792,6 +274351,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -273822,7 +274382,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273901,6 +274460,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -274037,6 +274597,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -274090,7 +274651,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -274098,49 +274658,13 @@ 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": 1731579000000, - "slot_end": 1731579600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -274391,12 +274915,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -274404,10 +274930,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, @@ -274434,7 +274992,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -274701,6 +275258,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -274878,7 +275436,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -274987,7 +275544,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -275124,7 +275680,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -275235,6 +275790,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -275250,6 +275806,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -275442,58 +275999,22 @@ 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, @@ -275747,6 +276268,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -275754,16 +276276,55 @@ 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, + "keywords": [ + "Encrypted", + "Mempool" + ], + "tags": [ + "encryption", + "mempool", + "Censorship Resistance", + "Core Protocol", + "Cryptography" + ], + "language": "en", + "speakers": [ + "marc-harvey-hill" + ], + "eventId": "devcon-7", + "slot_start": 1731466500000, + "slot_end": 1731467100000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -275784,7 +276345,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -276058,6 +276618,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -276313,7 +276874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276329,7 +276889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276517,11 +277076,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -276650,6 +277211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -276791,7 +277353,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276800,58 +277361,7 @@ 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, - "keywords": [ - "Encrypted", - "Mempool" - ], - "tags": [ - "encryption", - "mempool", - "Censorship Resistance", - "Core Protocol", - "Cryptography" - ], - "language": "en", - "speakers": [ - "marc-harvey-hill" - ], - "eventId": "devcon-7", - "slot_start": 1731466500000, - "slot_end": 1731467100000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -277115,10 +277625,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -277130,6 +277642,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, @@ -277273,6 +277821,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -277595,29 +278144,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -277730,7 +278256,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -277879,8 +278404,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -277905,6 +278428,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -277920,6 +278444,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -278007,6 +278532,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -278144,12 +278670,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -278161,42 +278685,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, @@ -278207,7 +278695,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -278339,7 +278826,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -278497,9 +278983,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -278512,6 +279000,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, @@ -278521,6 +279035,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -278943,7 +279458,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -278959,7 +279473,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -279047,7 +279560,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -279498,11 +280010,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -279515,32 +280025,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, @@ -279550,7 +280034,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -279849,8 +280332,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -279863,10 +280348,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, @@ -280161,6 +280683,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -280690,6 +281215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -280843,91 +281369,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 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, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -280985,6 +281426,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -281193,9 +281635,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -281250,9 +281689,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -281265,6 +281706,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, @@ -281566,6 +282058,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -281722,7 +282215,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281933,7 +282425,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -282008,6 +282499,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -282038,8 +282530,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -282196,11 +282690,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -282213,57 +282705,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, @@ -282358,6 +282799,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -282564,7 +283007,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -282619,6 +283061,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -282627,6 +283070,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -282634,6 +283078,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, @@ -282641,6 +283123,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -282936,6 +283419,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -283002,7 +283486,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -283033,10 +283516,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -283302,8 +283783,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -283380,6 +283859,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -283445,6 +283925,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -283564,7 +284046,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -283573,7 +284054,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -283581,44 +284061,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, @@ -283626,7 +284068,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -283720,6 +284161,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -283921,7 +284363,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -283980,10 +284421,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -283995,11 +284438,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, @@ -284298,6 +284792,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -284358,7 +284854,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -284424,8 +284919,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -284660,7 +285153,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -284739,6 +285231,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -284750,6 +285243,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -284786,6 +285280,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -284920,12 +285415,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -284937,62 +285430,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, @@ -285015,6 +285457,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -285071,6 +285514,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -285290,8 +285734,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -285351,9 +285793,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -285366,6 +285810,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, @@ -285377,6 +285860,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -285671,6 +286155,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -285726,7 +286212,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -285738,7 +286223,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -285775,7 +286259,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -285952,7 +286435,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -286009,7 +286491,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -286177,6 +286658,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286206,6 +286688,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286288,11 +286771,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -286305,45 +286786,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "enter-the-war-room-a-black-swan-simulation", - "sourceId": "HQSNWQ", - "title": "Enter the War Room: A Black Swan Simulation", - "description": "BREAKING: A key Layer 2 sequencer has suffered a complete outage for a brief period! As a consequence, many loans from the protocol DevaLend could not be paid, leading to liquidations and bad debt.\r\n\r\nIn this workshop, you will assume the role of one of the key players in this exciting simulation, and explore how to navigate through it. Propose how to navigate through the DevaLend situation and react as new scenarios evolve and respond to your ideas. Good Luck!", - "track": "Coordination", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": true, - "keywords": [ - "Conflict" - ], - "tags": [ - "Layer 2s", - "Governance", - "Emergency Plan", - "conflict", - "Emergency Plan", - "Governance", - "Layer 2s" - ], - "language": "en", - "speakers": [ - "juan-carlos-bell-llinas", - "oxytocin" - ], - "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731400200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1QJBCSyIk_2YgSpZlJQsuZo3ymwCCG1XhQXN6zxlSBoQ" - }, - "vector": [ 0, 0, 0, @@ -286355,8 +286797,8 @@ 0, 0, 0, - 6, 0, + 2, 0, 0, 0, @@ -286453,6 +286895,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286649,8 +287092,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -286713,6 +287154,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286721,6 +287163,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -286728,6 +287171,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, @@ -286743,6 +287219,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -287035,6 +287512,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -287149,7 +287628,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287179,7 +287657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287289,7 +287766,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287386,7 +287862,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287487,6 +287962,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -287645,7 +288121,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287654,7 +288129,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -287662,44 +288136,12 @@ 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, 0, 0, + 2, 0, 0, 0, @@ -287710,7 +288152,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -287810,6 +288251,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -288002,8 +288444,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -288071,12 +288511,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -288084,6 +288526,37 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "epf-day-panel", + "sourceId": "ZMRJ9B", + "title": "EPF Day Panel", + "description": "Panel with former fellows who became core devs and mentors", + "track": "[CLS] EPF Day", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "mario-havel", + "eniko-nagy", + "echo", + "eitan" + ], + "eventId": "devcon-7", + "slot_start": 1731489300000, + "slot_end": 1731492000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk" + }, + "vector": [ 0, 0, 0, @@ -288099,6 +288572,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -288391,7 +288865,11 @@ 0, 0, 0, + 6, 0, + 6, + 6, + 6, 0, 0, 0, @@ -288449,7 +288927,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -288628,7 +289105,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -288738,7 +289214,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -288998,14 +289473,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -289013,37 +289486,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "epf-day-panel", - "sourceId": "ZMRJ9B", - "title": "EPF Day Panel", - "description": "Panel with former fellows who became core devs and mentors", - "track": "[CLS] EPF Day", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "mario-havel", - "eniko-nagy", - "echo", - "eitan" - ], - "eventId": "devcon-7", - "slot_start": 1731489300000, - "slot_end": 1731492000000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk" - }, - "vector": [ 0, 0, 0, @@ -289059,7 +289501,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -289351,11 +289792,7 @@ 0, 0, 0, - 6, 0, - 6, - 6, - 6, 0, 0, 0, @@ -289425,9 +289862,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -289440,6 +289879,47 @@ 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": 0, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "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, @@ -289455,6 +289935,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -289752,6 +290233,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -290345,11 +290827,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -290362,47 +290842,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": 0, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "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, @@ -290418,7 +290857,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -290530,6 +290968,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -290715,7 +291155,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -290786,6 +291225,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -290798,6 +291242,39 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval", + "sourceId": "FARJAG", + "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval", + "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Cross-chain" + ], + "tags": [ + "Layer 2s", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "julien" + ], + "eventId": "devcon-7", + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc" + }, + "vector": [ 0, 0, 0, @@ -290805,6 +291282,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -291032,6 +291510,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -291447,8 +291926,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -291553,6 +292030,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -291606,6 +292084,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -291704,11 +292183,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -291721,39 +292198,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval", - "sourceId": "FARJAG", - "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval", - "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Cross-chain" - ], - "tags": [ - "Layer 2s", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "julien" - ], - "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc" - }, - "vector": [ 0, 0, 0, @@ -291761,8 +292205,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -291988,7 +292430,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -292139,9 +292580,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -292154,6 +292597,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "erc-4337-adoption-analysis", + "sourceId": "SGRFUA", + "title": "ERC-4337: Adoption Analysis", + "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space", + "track": "Usability", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": true, + "doNotRecord": false, + "keywords": [ + "ERC-4337" + ], + "tags": [ + "DevRel", + "Use Cases", + "Account Abstraction", + "erc-4337", + "Account Abstraction", + "DevRel", + "Use Cases" + ], + "language": "en", + "speakers": [ + "tom-teman" + ], + "eventId": "devcon-7", + "slot_start": 1731564000000, + "slot_end": 1731565800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA" + }, + "vector": [ 0, 0, 0, @@ -292162,6 +292643,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -292345,6 +292827,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -292505,7 +292988,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -292559,7 +293041,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -292948,6 +293429,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -292975,6 +293457,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -293055,7 +293538,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -293070,65 +293552,7 @@ 0, 0, 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "erc-4337-adoption-analysis", - "sourceId": "SGRFUA", - "title": "ERC-4337: Adoption Analysis", - "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space", - "track": "Usability", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": true, - "doNotRecord": false, - "keywords": [ - "ERC-4337" - ], - "tags": [ - "DevRel", - "Use Cases", - "Account Abstraction", - "erc-4337", - "Account Abstraction", - "DevRel", - "Use Cases" - ], - "language": "en", - "speakers": [ - "tom-teman" - ], - "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731565800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -293301,7 +293725,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -293519,11 +293942,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -293532,10 +293957,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "erigon-3-a-new-paradigm-for-ethereum-clients", + "sourceId": "CWZK8G", + "title": "Erigon 3 a New Paradigm for Ethereum Clients", + "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "efficiency", + "client", + "modular" + ], + "tags": [ + "Architecture", + "Data Availability", + "Scalability", + "modular", + "Architecture", + "Data Availability", + "Scalability" + ], + "language": "en", + "speakers": [ + "mark-holt" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731483000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -293845,6 +294311,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -293900,7 +294367,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -293928,7 +294394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -294012,7 +294477,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -294023,10 +294487,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -294342,10 +294802,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -294413,7 +294875,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -294428,62 +294889,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "erigon-3-a-new-paradigm-for-ethereum-clients", - "sourceId": "CWZK8G", - "title": "Erigon 3 a New Paradigm for Ethereum Clients", - "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "efficiency", - "client", - "modular" - ], - "tags": [ - "Architecture", - "Data Availability", - "Scalability", - "modular", - "Architecture", - "Data Availability", - "Scalability" - ], - "language": "en", - "speakers": [ - "mark-holt" - ], - "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731483000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -294642,6 +295047,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -294781,7 +295187,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -294897,6 +295302,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -294904,6 +295310,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -294912,10 +295319,60 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power", + "sourceId": "C3HTZP", + "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power", + "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "tags": [ + "Protocol Design", + "Censorship Resistance", + "Decentralization", + "MEV", + "Censorship Resistance", + "MEV", + "Protocol Design" + ], + "keywords": [ + "TEE", + "hardware", + "decentralization" + ], + "duration": 1502, + "language": "en", + "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11", + "sources_youtubeId": "ySVYt6MUrHM", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt", + "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.", + "eventId": "devcon-7", + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js", + "resources_slides": null, + "speakers": [ + "philip-daian" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -295226,6 +295683,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -295269,12 +295727,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -295347,7 +295803,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295514,7 +295969,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295659,6 +296113,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -295702,6 +296157,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -295757,6 +296213,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -295769,7 +296226,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295777,7 +296233,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -295786,60 +296241,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power", - "sourceId": "C3HTZP", - "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power", - "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "tags": [ - "Protocol Design", - "Censorship Resistance", - "Decentralization", - "MEV", - "Censorship Resistance", - "MEV", - "Protocol Design" - ], - "keywords": [ - "TEE", - "hardware", - "decentralization" - ], - "duration": 1502, - "language": "en", - "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11", - "sources_youtubeId": "ySVYt6MUrHM", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt", - "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.", - "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js", - "resources_slides": null, - "speakers": [ - "philip-daian" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -295854,6 +296259,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -296149,7 +296555,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -296268,6 +296673,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -296276,6 +296682,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -296283,12 +296690,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum", + "sourceId": "TA3N8E", + "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum", + "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Ethereum", + "for", + "Good" + ], + "tags": [ + "Decentralization", + "Local Impact", + "Social Recovery", + "ethereum", + "good", + "Decentralization", + "Local Impact", + "Social Recovery" + ], + "language": "en", + "speakers": [ + "andres-forigua", + "william-martinez", + "mateo-sabogal" + ], + "eventId": "devcon-7", + "slot_start": 1731660600000, + "slot_end": 1731661200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -296576,7 +297027,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -296599,6 +297049,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -296620,7 +297073,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -296676,7 +297128,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -296722,7 +297173,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -297128,6 +297578,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -297136,7 +297590,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -297145,7 +297598,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -297153,56 +297605,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum", - "sourceId": "TA3N8E", - "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum", - "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Ethereum", - "for", - "Good" - ], - "tags": [ - "Decentralization", - "Local Impact", - "Social Recovery", - "ethereum", - "good", - "Decentralization", - "Local Impact", - "Social Recovery" - ], - "language": "en", - "speakers": [ - "andres-forigua", - "william-martinez", - "mateo-sabogal" - ], - "eventId": "devcon-7", - "slot_start": 1731660600000, - "slot_end": 1731661200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -297236,6 +297644,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -297312,6 +297721,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -297374,6 +297784,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -297511,9 +297924,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -297630,9 +298040,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, + 2, 0, 0, 0, @@ -297640,6 +298055,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eth-escape-winner-revealed", + "sourceId": "WXS8BH", + "title": "ETH Escape Winner Revealed", + "description": "We'll announce the winner of ETH Escape.", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "michael-okeeffe" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731580200000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1lSwPhaKp0iIdGqbNHH0Wq_hG_vGPCW1ja_5qbLVLScg" + }, + "vector": [ 0, 0, 0, @@ -297659,6 +298102,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -297958,6 +298402,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -298037,7 +298482,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -298103,7 +298547,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -298180,7 +298623,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -298243,7 +298685,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -298499,14 +298940,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -298514,45 +298953,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eth-is-permissionless-money", - "sourceId": "TMFPCF", - "title": "ETH is permissionless money", - "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Censorship Resistance", - "Decentralization", - "Ethereum Roadmap" - ], - "language": "en", - "speakers": [ - "mike-neuder" - ], - "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY" - }, - "vector": [ - 0, - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -298864,8 +299264,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -298991,8 +299389,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -299005,8 +299405,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eth-is-permissionless-money", + "sourceId": "TMFPCF", + "title": "ETH is permissionless money", + "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Censorship Resistance", + "Decentralization", + "Ethereum Roadmap" + ], + "language": "en", + "speakers": [ + "mike-neuder" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731571200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -299324,6 +299757,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -299387,7 +299821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299433,7 +299866,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299479,7 +299911,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -299849,7 +300280,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -299864,81 +300294,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-a-force-of-good", - "sourceId": "HUZP7J", - "title": "Ethereum a Force of Good", - "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "stablecoins", - "supply chain", - "agriculture", - "scalability" - ], - "tags": [ - "RWA", - "Ethereum for Good", - "Economics", - "micropayments", - "Economics", - "Ethereum for Good", - "RWA" - ], - "language": "en", - "speakers": [ - "stani-kulechov" - ], - "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -299973,6 +300328,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -300018,6 +300374,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -300224,7 +300581,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -300388,8 +300744,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -300401,12 +300759,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-a-force-of-good", + "sourceId": "HUZP7J", + "title": "Ethereum a Force of Good", + "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "stablecoins", + "supply chain", + "agriculture", + "scalability" + ], + "tags": [ + "RWA", + "Ethereum for Good", + "Economics", + "micropayments", + "Economics", + "Ethereum for Good", + "RWA" + ], + "language": "en", + "speakers": [ + "stani-kulechov" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -300679,7 +301079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300722,6 +301121,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -300770,7 +301170,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300798,7 +301197,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -300953,7 +301351,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -301181,6 +301578,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -301208,13 +301606,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -301223,53 +301619,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-and-robots", - "sourceId": "9G9LSH", - "title": "Ethereum and Robots", - "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Robots" - ], - "tags": [ - "Collective Intelligence", - "Civil Resistance", - "DePIN", - "Autonomous World", - "robots", - "Autonomous World", - "Civil Resistance", - "Collective Intelligence", - "DePIN" - ], - "language": "en", - "speakers": [ - "tomasz-stanczak" - ], - "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -301314,6 +301669,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -301341,6 +301697,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -301495,6 +301852,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -301583,7 +301941,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -301750,11 +302107,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -301763,12 +302122,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-and-robots", + "sourceId": "9G9LSH", + "title": "Ethereum and Robots", + "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Robots" + ], + "tags": [ + "Collective Intelligence", + "Civil Resistance", + "DePIN", + "Autonomous World", + "robots", + "Autonomous World", + "Civil Resistance", + "Collective Intelligence", + "DePIN" + ], + "language": "en", + "speakers": [ + "tomasz-stanczak" + ], + "eventId": "devcon-7", + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -302024,7 +302424,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -302036,7 +302435,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -302086,6 +302484,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -302112,7 +302511,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -302234,7 +302632,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -302312,7 +302709,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -302531,6 +302927,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -302542,6 +302939,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -302566,13 +302964,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -302581,51 +302977,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-citizen-embracing-self-sovereign-digital-identity", - "sourceId": "ATKWT8", - "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity", - "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Attestations", - "data" - ], - "tags": [ - "Privacy", - "Identity", - "Social", - "data", - "Identity", - "Privacy", - "Social" - ], - "language": "en", - "speakers": [ - "vid-kersic" - ], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731647400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -302659,6 +303015,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -302780,6 +303137,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -302857,6 +303215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -302941,7 +303300,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -303111,6 +303469,73 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-citizen-embracing-self-sovereign-digital-identity", + "sourceId": "ATKWT8", + "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity", + "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Attestations", + "data" + ], + "tags": [ + "Privacy", + "Identity", + "Social", + "data", + "Identity", + "Privacy", + "Social" + ], + "language": "en", + "speakers": [ + "vid-kersic" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731647400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -303408,7 +303833,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303422,6 +303846,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -303476,7 +303901,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303539,7 +303963,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303670,7 +304093,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303893,6 +304315,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -303921,7 +304344,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303930,7 +304352,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -303938,49 +304359,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-culture-expanding-in-the-infinite-garden", - "sourceId": "ZS338S", - "title": "Ethereum Culture Expanding in the Infinite Garden", - "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Culture", - "Subculture", - "Infinite Garden" - ], - "tags": [ - "Values", - "infinite", - "garden", - "Values" - ], - "language": "en", - "speakers": [ - "tomo-saito" - ], - "eventId": "devcon-7", - "slot_start": 1731649200000, - "slot_end": 1731650400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -304000,6 +304383,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304037,7 +304421,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -304063,6 +304446,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304193,6 +304577,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304443,6 +304828,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304451,6 +304837,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -304458,11 +304845,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-culture-expanding-in-the-infinite-garden", + "sourceId": "ZS338S", + "title": "Ethereum Culture Expanding in the Infinite Garden", + "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Culture", + "Subculture", + "Infinite Garden" + ], + "tags": [ + "Values", + "infinite", + "garden", + "Values" + ], + "language": "en", + "speakers": [ + "tomo-saito" + ], + "eventId": "devcon-7", + "slot_start": 1731649200000, + "slot_end": 1731650400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -304520,6 +304945,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -304826,7 +305252,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -305026,8 +305451,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -305278,14 +305701,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -305293,54 +305714,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-execution-layer-specifications-eels", - "sourceId": "3GCD7S", - "title": "Ethereum Execution Layer Specifications (EELS)", - "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "tags": [ - "Core Protocol", - "Layer 1" - ], - "keywords": [ - "Execution", - "Layer" - ], - "duration": 1253, - "language": "en", - "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802", - "sources_youtubeId": "WEvCFg0Z1D4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt", - "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c", - "resources_slides": null, - "speakers": [ - "guruprasad-kamath" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -305360,6 +305737,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -305559,6 +305937,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -305658,7 +306038,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -305810,12 +306189,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -305823,10 +306204,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-execution-layer-specifications-eels", + "sourceId": "3GCD7S", + "title": "Ethereum Execution Layer Specifications (EELS)", + "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "tags": [ + "Core Protocol", + "Layer 1" + ], + "keywords": [ + "Execution", + "Layer" + ], + "duration": 1253, + "language": "en", + "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802", + "sources_youtubeId": "WEvCFg0Z1D4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt", + "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.", + "eventId": "devcon-7", + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c", + "resources_slides": null, + "speakers": [ + "guruprasad-kamath" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -306090,11 +306515,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -306148,6 +306571,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -306581,9 +307005,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -306637,13 +307063,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -306654,43 +307078,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-in-30-minutes", - "sourceId": "GAJPCN", - "title": "Ethereum in 30 minutes", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "vitalik-buterin" - ], - "eventId": "devcon-7", - "slot_start": 1731384000000, - "slot_end": 1731385800000, - "slot_roomId": "main-stage", - "sources_youtubeId": "ei3tDRMjw6k", - "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9", - "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -306878,7 +307271,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -307160,11 +307552,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -307175,12 +307569,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-in-30-minutes", + "sourceId": "GAJPCN", + "title": "Ethereum in 30 minutes", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "vitalik-buterin" + ], + "eventId": "devcon-7", + "slot_start": 1731384000000, + "slot_end": 1731385800000, + "slot_roomId": "main-stage", + "sources_youtubeId": "ei3tDRMjw6k", + "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9", + "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -307369,6 +307794,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -307986,10 +308413,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -308002,48 +308427,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires", - "sourceId": "9HFAES", - "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires", - "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Academic", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Education" - ], - "tags": [ - "Design Thinking", - "Ethereum for Good", - "Public good" - ], - "language": "en", - "speakers": [ - "romina-sejas", - "juan-david-reyes" - ], - "eventId": "devcon-7", - "slot_start": 1731559200000, - "slot_end": 1731559800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -308360,8 +308749,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -308518,6 +308905,10 @@ 0, 0, 0, + 2, + 0, + 0, + 2, 0, 0, 0, @@ -308527,12 +308918,51 @@ 0, 0, 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires", + "sourceId": "9HFAES", + "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires", + "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Academic", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Education" + ], + "tags": [ + "Design Thinking", + "Ethereum for Good", + "Public good" + ], + "language": "en", + "speakers": [ + "romina-sejas", + "juan-david-reyes" + ], + "eventId": "devcon-7", + "slot_start": 1731559200000, + "slot_end": 1731559800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -308851,6 +309281,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -308885,7 +309317,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -308902,7 +309333,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -308920,7 +309350,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -309340,71 +309769,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-needs-native-l2", - "sourceId": "9RNWDX", - "title": "Ethereum needs native L2", - "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "interoperability" - ], - "tags": [ - "Cross-L2", - "Ethereum Roadmap", - "Scalability" - ], - "language": "en", - "speakers": [ - "koeppelmann" - ], - "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -309444,6 +309808,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -309460,6 +309825,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -309477,6 +309843,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -309568,7 +309935,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -309897,6 +310263,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -309907,9 +310274,44 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-needs-native-l2", + "sourceId": "9RNWDX", + "title": "Ethereum needs native L2", + "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "interoperability" + ], + "tags": [ + "Cross-L2", + "Ethereum Roadmap", + "Scalability" + ], + "language": "en", + "speakers": [ + "koeppelmann" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A" + }, + "vector": [ 0, 0, 0, @@ -309917,6 +310319,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -310089,6 +310492,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -310268,7 +310672,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310322,7 +310725,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310330,7 +310732,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -310690,11 +311091,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -310707,52 +311106,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-privacy-ecosystem-overview", - "sourceId": "GDSWLR", - "title": "Ethereum Privacy Ecosystem overview", - "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "hackathons", - "funding", - "" - ], - "tags": [ - "Privacy", - "Censorship Resistance", - "Use Cases", - "funding", - "Censorship Resistance", - "Privacy", - "Use Cases" - ], - "language": "en", - "speakers": [ - "mykola-siusko" - ], - "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731398400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -310837,6 +311195,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -310890,6 +311249,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -310897,6 +311257,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -311072,7 +311433,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -311257,9 +311617,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -311272,11 +311634,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-privacy-ecosystem-overview", + "sourceId": "GDSWLR", + "title": "Ethereum Privacy Ecosystem overview", + "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "hackathons", + "funding", + "" + ], + "tags": [ + "Privacy", + "Censorship Resistance", + "Use Cases", + "funding", + "Censorship Resistance", + "Privacy", + "Use Cases" + ], + "language": "en", + "speakers": [ + "mykola-siusko" + ], + "eventId": "devcon-7", + "slot_start": 1731396600000, + "slot_end": 1731398400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -311565,7 +311968,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -311599,11 +312001,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -311634,7 +312036,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -311800,7 +312201,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -312050,14 +312450,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -312065,56 +312463,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereum-real-world-economy", - "sourceId": "JSYMFD", - "title": "Ethereum Real World Economy", - "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "stablecoins", - "real-world-use", - "use-cases" - ], - "tags": [ - "Ethereum Roadmap", - "Use Cases", - "e/acc", - "case", - "use", - "e/acc", - "Ethereum Roadmap", - "Use Cases" - ], - "language": "en", - "speakers": [ - "nalin-b", - "dc-posch", - "liam-horne" - ], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731574800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -312142,6 +312496,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312179,6 +312534,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312209,6 +312565,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312253,7 +312610,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -312313,7 +312669,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -312376,6 +312731,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -312434,7 +312790,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -312626,12 +312981,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -312639,12 +312996,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereum-real-world-economy", + "sourceId": "JSYMFD", + "title": "Ethereum Real World Economy", + "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "stablecoins", + "real-world-use", + "use-cases" + ], + "tags": [ + "Ethereum Roadmap", + "Use Cases", + "e/acc", + "case", + "use", + "e/acc", + "Ethereum Roadmap", + "Use Cases" + ], + "language": "en", + "speakers": [ + "nalin-b", + "dc-posch", + "liam-horne" + ], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731574800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -312784,6 +313185,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -312843,6 +313245,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -312926,7 +313329,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -312965,6 +313367,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -313003,7 +313407,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -313041,7 +313444,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -313162,7 +313564,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -313411,9 +313812,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -313426,45 +313825,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter", - "sourceId": "XSCFZR", - "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter", - "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Autonomous World", - "Gaming", - "Use Cases" - ], - "language": "en", - "speakers": [ - "dhrumil-shah" - ], - "eventId": "devcon-7", - "slot_start": 1731494400000, - "slot_end": 1731496200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -313495,6 +313861,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -313534,7 +313907,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -313566,6 +313938,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -313596,6 +313976,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -313715,6 +314097,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -313962,7 +314346,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -313975,12 +314361,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter", + "sourceId": "XSCFZR", + "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter", + "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Autonomous World", + "Gaming", + "Use Cases" + ], + "language": "en", + "speakers": [ + "dhrumil-shah" + ], + "eventId": "devcon-7", + "slot_start": 1731494400000, + "slot_end": 1731496200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -314051,6 +314470,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -314276,7 +314696,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -314307,8 +314726,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -314761,9 +315178,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -314776,56 +315191,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now", - "sourceId": "UHAESN", - "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now", - "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?", - "track": "Cypherpunk & Privacy", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ethos", - "values", - "alignment" - ], - "tags": [ - "Layer 1", - "Ethereum Roadmap", - "Coordination", - "alignment", - "Coordination", - "Ethereum Roadmap", - "Layer 1" - ], - "language": "en", - "speakers": [ - "peter-szilagyi", - "ahmad-bitar", - "phil-ngo", - "nixo", - "mark-tyneway" - ], - "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731567600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -314845,6 +315215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -314875,6 +315246,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -314992,7 +315365,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -315081,7 +315453,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -315147,9 +315518,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -315332,7 +315700,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -315345,11 +315715,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now", + "sourceId": "UHAESN", + "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now", + "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?", + "track": "Cypherpunk & Privacy", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ethos", + "values", + "alignment" + ], + "tags": [ + "Layer 1", + "Ethereum Roadmap", + "Coordination", + "alignment", + "Coordination", + "Ethereum Roadmap", + "Layer 1" + ], + "language": "en", + "speakers": [ + "peter-szilagyi", + "ahmad-bitar", + "phil-ngo", + "nixo", + "mark-tyneway" + ], + "eventId": "devcon-7", + "slot_start": 1731564000000, + "slot_end": 1731567600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -315517,6 +315932,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -315574,7 +315990,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -315606,6 +316021,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -315672,6 +316088,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -315714,7 +316133,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -315753,7 +316171,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -315875,7 +316292,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -316101,6 +316517,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -316121,7 +316538,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -316130,7 +316546,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -316138,52 +316553,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethersjs-api-hidden-gems", - "sourceId": "EG8ML8", - "title": "Ethers.js - API Hidden Gems", - "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Ethers", - "API" - ], - "tags": [ - "DevEx", - "Testing", - "UI/UX", - "api", - "DevEx", - "Testing", - "UI/UX" - ], - "language": "en", - "speakers": [ - "richard-moore" - ], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac" - }, - "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -316288,6 +316657,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316326,6 +316696,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316447,6 +316818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316507,7 +316879,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -316693,6 +317064,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316701,6 +317073,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -316708,9 +317081,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethersjs-api-hidden-gems", + "sourceId": "EG8ML8", + "title": "Ethers.js - API Hidden Gems", + "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Ethers", + "API" + ], + "tags": [ + "DevEx", + "Testing", + "UI/UX", + "api", + "DevEx", + "Testing", + "UI/UX" + ], + "language": "en", + "speakers": [ + "richard-moore" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -316946,7 +317359,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -316975,7 +317387,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -317041,6 +317452,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -317159,7 +317571,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -317233,7 +317644,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -317478,7 +317888,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -317495,40 +317904,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ethos-dgen1-self-sovereign-os-hardware", - "sourceId": "TALWUM", - "title": "ethOS + dGEN1: Self sovereign OS + Hardware", - "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "DePIN", - "Mobile", - "UI/UX" - ], - "language": "en", - "speakers": [ - "markus-haas" - ], - "eventId": "devcon-7", - "slot_start": 1731576900000, - "slot_end": 1731577800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -317546,6 +317922,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -317729,6 +318106,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -317802,6 +318180,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -317858,7 +318237,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -318047,11 +318425,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -318062,7 +318442,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ethos-dgen1-self-sovereign-os-hardware", + "sourceId": "TALWUM", + "title": "ethOS + dGEN1: Self sovereign OS + Hardware", + "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "DePIN", + "Mobile", + "UI/UX" + ], + "language": "en", + "speakers": [ + "markus-haas" + ], + "eventId": "devcon-7", + "slot_start": 1731576900000, + "slot_end": 1731577800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -318288,8 +318701,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -318325,7 +318736,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -318397,6 +318807,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -318829,9 +319240,6 @@ 0, 0, 2, - 0, - 0, - 0, 2, 0, 0, @@ -318845,80 +319253,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum", - "sourceId": "QLK8UE", - "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum", - "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "MUD", - "EVE Frontier", - "EVE Online" - ], - "tags": [ - "Gaming", - "Autonomous World", - "eve", - "online", - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "justin-glibert", - "hilmar-petursson" - ], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk" - }, - "vector": [ - 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, @@ -318942,6 +319276,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -319071,7 +319406,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -319217,7 +319551,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -319446,9 +319779,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -319461,12 +319796,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum", + "sourceId": "QLK8UE", + "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum", + "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "MUD", + "EVE Frontier", + "EVE Online" + ], + "tags": [ + "Gaming", + "Autonomous World", + "eve", + "online", + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "justin-glibert", + "hilmar-petursson" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -319647,6 +320023,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -319734,8 +320111,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -319795,6 +320170,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -319942,8 +320318,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -320188,9 +320562,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -320203,40 +320575,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "eve-frontier-mud-day-demo", - "sourceId": "RMKJTL", - "title": "EVE Frontier - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": true, - "keywords": [], - "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "toniya-sundaram", - "scott-mccabe" - ], - "eventId": "devcon-7", - "slot_start": 1731556500000, - "slot_end": 1731556800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI" - }, - "vector": [ 0, 0, 0, @@ -320249,7 +320587,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -320352,6 +320689,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -320388,8 +320727,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -320560,6 +320897,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -320804,7 +321143,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -320817,6 +321158,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "eve-frontier-mud-day-demo", + "sourceId": "RMKJTL", + "title": "EVE Frontier - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": true, + "keywords": [], + "tags": [ + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "toniya-sundaram", + "scott-mccabe" + ], + "eventId": "devcon-7", + "slot_start": 1731556500000, + "slot_end": 1731556800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI" + }, + "vector": [ 0, 0, 0, @@ -320829,6 +321204,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -320968,6 +321344,9 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, @@ -321086,8 +321465,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -321540,13 +321917,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -321555,51 +321930,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "everything-you-need-to-know-about-state-expiry", - "sourceId": "MZXQKJ", - "title": "Everything you need to know about state expiry", - "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Statelessness", - "State expiry" - ], - "tags": [ - "Core Protocol", - "Protocol Design", - "Verkle trees", - "state", - "expiry", - "Core Protocol", - "Protocol Design", - "Verkle trees" - ], - "language": "en", - "speakers": [ - "han" - ], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -321711,6 +322045,21 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -321928,7 +322277,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -322150,10 +322498,68 @@ 0, 0, 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "everything-you-need-to-know-about-state-expiry", + "sourceId": "MZXQKJ", + "title": "Everything you need to know about state expiry", + "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Statelessness", + "State expiry" + ], + "tags": [ + "Core Protocol", + "Protocol Design", + "Verkle trees", + "state", + "expiry", + "Core Protocol", + "Protocol Design", + "Verkle trees" + ], + "language": "en", + "speakers": [ + "han" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA" + }, + "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -322353,7 +322759,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322380,7 +322785,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322485,6 +322889,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -322529,7 +322934,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -322654,8 +323058,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -322896,77 +323298,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "evm-charts-2024-whats-hot-whats-not", - "sourceId": "R3UPGT", - "title": "EVM Charts 2024: What's hot? What's not?", - "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Opcodes", - "Precompiles", - "EVM Metrics", - "Protocol Optimization", - "Statistics", - "evm usage trends" - ], - "tags": [ - "Core Protocol", - "Architecture", - "Gas", - "EVM", - "trend", - "usage", - "Architecture", - "Core Protocol", - "Gas" - ], - "language": "en", - "speakers": [ - "dominic-bruetsch" - ], - "eventId": "devcon-7", - "slot_start": 1731471000000, - "slot_end": 1731471600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -322985,6 +323316,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -323011,6 +323343,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -323159,6 +323492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -323283,6 +323617,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -323292,7 +323628,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -323524,9 +323859,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -323539,10 +323876,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "evm-charts-2024-whats-hot-whats-not", + "sourceId": "R3UPGT", + "title": "EVM Charts 2024: What's hot? What's not?", + "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Opcodes", + "Precompiles", + "EVM Metrics", + "Protocol Optimization", + "Statistics", + "evm usage trends" + ], + "tags": [ + "Core Protocol", + "Architecture", + "Gas", + "EVM", + "trend", + "usage", + "Architecture", + "Core Protocol", + "Gas" + ], + "language": "en", + "speakers": [ + "dominic-bruetsch" + ], + "eventId": "devcon-7", + "slot_start": 1731471000000, + "slot_end": 1731471600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -323716,7 +324099,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -323759,7 +324141,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -323876,6 +324257,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -323906,7 +324288,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -323927,7 +324308,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -324019,8 +324399,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -324259,12 +324637,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -324276,36 +324652,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "evm-memory-repricing-and-gentest", - "sourceId": "MTWH38", - "title": "EVM Memory Repricing & Gentest", - "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": true, - "keywords": [], - "tags": [ - "EVM-equivalent" - ], - "language": "en", - "speakers": [ - "raxhvl" - ], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731469500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY" - }, - "vector": [ 0, 0, 0, @@ -324321,7 +324667,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -324338,6 +324683,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -324380,6 +324726,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -324526,6 +324873,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -324546,6 +324894,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -324637,11 +324986,12 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -324876,10 +325226,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -324891,6 +325243,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "evm-memory-repricing-and-gentest", + "sourceId": "MTWH38", + "title": "EVM Memory Repricing & Gentest", + "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": true, + "keywords": [], + "tags": [ + "EVM-equivalent" + ], + "language": "en", + "speakers": [ + "raxhvl" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731469500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY" + }, + "vector": [ 0, 0, 0, @@ -324906,6 +325288,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -325227,6 +325610,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -325369,7 +325753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -325607,12 +325990,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -325624,57 +326005,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "evm-object-format-eof-history-and-motivation", - "sourceId": "SEUZGU", - "title": "EVM Object Format (EOF) - History and motivation", - "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Core Protocol", - "developer", - "experience", - "Core", - "Protocol" - ], - "keywords": [ - "EVM", - "Developer Experience" - ], - "duration": 1503, - "language": "en", - "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496", - "sources_youtubeId": "X2mlptWzphc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro", - "resources_slides": null, - "speakers": [ - "danno-ferrin" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -326006,7 +326340,7 @@ 0, 0, 0, - 6, + 2, 0, 0, 0, @@ -326244,10 +326578,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -326259,10 +326595,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "evm-object-format-eof-history-and-motivation", + "sourceId": "SEUZGU", + "title": "EVM Object Format (EOF) - History and motivation", + "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Core Protocol", + "developer", + "experience", + "Core", + "Protocol" + ], + "keywords": [ + "EVM", + "Developer Experience" + ], + "duration": 1503, + "language": "en", + "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496", + "sources_youtubeId": "X2mlptWzphc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro", + "resources_slides": null, + "speakers": [ + "danno-ferrin" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -326428,7 +326811,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -326584,7 +326966,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -326598,6 +326979,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -326714,8 +327097,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -326734,7 +327115,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -326971,11 +327351,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -326988,51 +327366,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "evm-object-format-eof-managing-the-bytecode-chaos", - "sourceId": "UU9BTK", - "title": "EVM Object Format (EOF): Managing the Bytecode Chaos", - "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EOF", - "EIP", - "upgrades" - ], - "tags": [ - "Ethereum Roadmap", - "Protocol Design", - "Security", - "upgrade", - "Ethereum Roadmap", - "Protocol Design", - "Security" - ], - "language": "en", - "speakers": [ - "alex-murashkin" - ], - "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -327066,6 +327403,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -327220,6 +327559,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -327349,6 +327689,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -327365,7 +327707,14 @@ 0, 0, 0, - 6, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -327597,16 +327946,68 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "evm-object-format-eof-managing-the-bytecode-chaos", + "sourceId": "UU9BTK", + "title": "EVM Object Format (EOF): Managing the Bytecode Chaos", + "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EOF", + "EIP", + "upgrades" + ], + "tags": [ + "Ethereum Roadmap", + "Protocol Design", + "Security", + "upgrade", + "Ethereum Roadmap", + "Protocol Design", + "Security" + ], + "language": "en", + "speakers": [ + "alex-murashkin" + ], + "eventId": "devcon-7", + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -327767,7 +328168,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -327813,7 +328213,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -327943,6 +328342,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -327961,7 +328361,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -328093,7 +328492,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -328329,11 +328727,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -328346,41 +328742,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "evmmax-fast-modular-arithmetic-in-evm", - "sourceId": "7CWEHH", - "title": "EVMMAX. Fast Modular Arithmetic in EVM", - "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EOF", - "EVM" - ], - "tags": [ - "Cryptography", - "EVM", - "Cryptography" - ], - "language": "en", - "speakers": [ - "rodiazet" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk" - }, - "vector": [ 0, 0, 0, @@ -328431,6 +328792,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -328575,6 +328940,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -328706,6 +329072,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -328719,7 +329086,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -328942,6 +329308,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -328954,10 +329325,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "evmmax-fast-modular-arithmetic-in-evm", + "sourceId": "7CWEHH", + "title": "EVMMAX. Fast Modular Arithmetic in EVM", + "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EOF", + "EVM" + ], + "tags": [ + "Cryptography", + "EVM", + "Cryptography" + ], + "language": "en", + "speakers": [ + "rodiazet" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -329133,7 +329540,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -329294,6 +329700,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -329329,7 +329736,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -329682,13 +330088,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -329699,52 +330103,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "evolution-of-scams", - "sourceId": "WZWPE9", - "title": "Evolution of Scams", - "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "metamask", - "Hacks", - "Security" - ], - "keywords": [ - "Security", - "Drainers", - "MetaMask" - ], - "duration": 558, - "language": "en", - "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537", - "sources_youtubeId": "SgkEwSDkBnI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt", - "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", - "eventId": "devcon-7", - "slot_start": 1731408600000, - "slot_end": 1731409200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0", - "resources_slides": null, - "speakers": [ - "ohm" - ] - }, - "vector": [ - 6, 0, 0, 0, @@ -329758,6 +330116,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -329953,6 +330312,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -330083,7 +330443,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -330306,11 +330665,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -330321,6 +330682,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "evolution-of-scams", + "sourceId": "WZWPE9", + "title": "Evolution of Scams", + "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "metamask", + "Hacks", + "Security" + ], + "keywords": [ + "Security", + "Drainers", + "MetaMask" + ], + "duration": 558, + "language": "en", + "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537", + "sources_youtubeId": "SgkEwSDkBnI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt", + "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", + "eventId": "devcon-7", + "slot_start": 1731408600000, + "slot_end": 1731409200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0", + "resources_slides": null, + "speakers": [ + "ohm" + ] + }, + "vector": [ + 6, 0, 0, 0, @@ -330483,7 +330890,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -330662,6 +331068,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -330735,7 +331142,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -330810,7 +331216,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -331045,12 +331450,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -331062,50 +331465,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "exploring-auction-mechanisms-in-protocol-design", - "sourceId": "WAKEL9", - "title": "Exploring Auction Mechanisms in Protocol Design", - "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Auction" - ], - "tags": [ - "Core Protocol", - "Economics", - "MEV", - "auction", - "Core Protocol", - "Economics", - "MEV" - ], - "language": "en", - "speakers": [ - "terence" - ], - "eventId": "devcon-7", - "slot_start": 1731485400000, - "slot_end": 1731486000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -331357,6 +331722,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -331431,6 +331797,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -331440,7 +331807,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -331666,10 +332032,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -331681,8 +332049,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "exploring-auction-mechanisms-in-protocol-design", + "sourceId": "WAKEL9", + "title": "Exploring Auction Mechanisms in Protocol Design", + "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Auction" + ], + "tags": [ + "Core Protocol", + "Economics", + "MEV", + "auction", + "Core Protocol", + "Economics", + "MEV" + ], + "language": "en", + "speakers": [ + "terence" + ], + "eventId": "devcon-7", + "slot_start": 1731485400000, + "slot_end": 1731486000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -331841,7 +332248,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -331858,7 +332264,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -331874,7 +332279,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -332025,6 +332429,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -332167,7 +332572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -332403,9 +332807,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -332418,40 +332820,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "exploring-mud-worlds-with-blockscout", - "sourceId": "QTLXWL", - "title": "Exploring MUD worlds with Blockscout", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Block", - "Explorers" - ], - "tags": [ - "Appchains", - "Interface" - ], - "language": "en", - "speakers": [ - "kirill-fedoseev" - ], - "eventId": "devcon-7", - "slot_start": 1731555300000, - "slot_end": 1731555600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro" - }, - "vector": [ 0, 0, 0, @@ -332481,6 +332849,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -332496,6 +332865,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -332788,31 +333158,7 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, + 2, 0, 0, 0, @@ -333048,7 +333394,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -333061,6 +333409,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "exploring-mud-worlds-with-blockscout", + "sourceId": "QTLXWL", + "title": "Exploring MUD worlds with Blockscout", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Block", + "Explorers" + ], + "tags": [ + "Appchains", + "Interface" + ], + "language": "en", + "speakers": [ + "kirill-fedoseev" + ], + "eventId": "devcon-7", + "slot_start": 1731555300000, + "slot_end": 1731555600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro" + }, + "vector": [ 0, 0, 0, @@ -333073,6 +333455,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -333333,7 +333716,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -333404,6 +333786,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -333520,7 +333904,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -333755,9 +334138,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -333770,56 +334151,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum", - "sourceId": "TVSAZU", - "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.", - "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Identity", - "Privacy", - "Zero-Knowledge" - ], - "keywords": [ - "N/A" - ], - "duration": 1479, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "q3rpu8aDRA8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs", - "resources_slides": null, - "speakers": [ - "remco-bloeman" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -333991,6 +334328,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -334155,7 +334501,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -334170,6 +334515,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -334397,18 +334750,71 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum", + "sourceId": "TVSAZU", + "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.", + "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Identity", + "Privacy", + "Zero-Knowledge" + ], + "keywords": [ + "N/A" + ], + "duration": 1479, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "q3rpu8aDRA8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731409200000, + "slot_end": 1731411000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs", + "resources_slides": null, + "speakers": [ + "remco-bloeman" + ] + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -334564,7 +334970,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -334601,7 +335006,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -334669,7 +335073,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -334749,6 +335152,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -335114,11 +335518,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -335131,51 +335533,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "exploring-the-future-of-account-abstraction", - "sourceId": "S7NYUJ", - "title": "Exploring the Future of Account Abstraction", - "description": "Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": true, - "doNotRecord": false, - "keywords": [ - "AA", - "roadmap" - ], - "tags": [ - "Ethereum Roadmap", - "In-protocol Account Abstraction", - "Account Abstraction", - "aa", - "roadmap", - "Account Abstraction", - "Ethereum Roadmap", - "In-protocol Account Abstraction" - ], - "language": "en", - "speakers": [ - "yoav-weiss" - ], - "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731562200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -335202,6 +335563,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -335238,6 +335600,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -335305,6 +335668,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -335514,7 +335878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -335750,9 +336113,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -335765,10 +336130,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "exploring-the-future-of-account-abstraction", + "sourceId": "S7NYUJ", + "title": "Exploring the Future of Account Abstraction", + "description": "Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": true, + "doNotRecord": false, + "keywords": [ + "AA", + "roadmap" + ], + "tags": [ + "Ethereum Roadmap", + "In-protocol Account Abstraction", + "Account Abstraction", + "aa", + "roadmap", + "Account Abstraction", + "Ethereum Roadmap", + "In-protocol Account Abstraction" + ], + "language": "en", + "speakers": [ + "yoav-weiss" + ], + "eventId": "devcon-7", + "slot_start": 1731560400000, + "slot_end": 1731562200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -335961,7 +336367,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -336104,13 +336509,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -336131,7 +336536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -336240,8 +336644,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -336472,13 +336874,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -336489,60 +336889,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols", - "sourceId": "LGZYYW", - "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols", - "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "TEE" - ], - "tags": [ - "TEE", - "Decentralization", - "Homomorphic Encryption", - "Intents", - "MPC", - "ZKP" - ], - "language": "en", - "speakers": [ - "mounir-benchemled" - ], - "eventId": "devcon-7", - "slot_start": 1731558000000, - "slot_end": 1731558600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -336618,6 +336964,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -336760,6 +337107,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -336786,6 +337134,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -336870,7 +337219,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -336895,6 +337243,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -337125,11 +337475,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -337140,6 +337492,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols", + "sourceId": "LGZYYW", + "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols", + "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "TEE" + ], + "tags": [ + "TEE", + "Decentralization", + "Homomorphic Encryption", + "Intents", + "MPC", + "ZKP" + ], + "language": "en", + "speakers": [ + "mounir-benchemled" + ], + "eventId": "devcon-7", + "slot_start": 1731558000000, + "slot_end": 1731558600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8" + }, + "vector": [ 0, 0, 0, @@ -337148,6 +337537,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -337320,7 +337710,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337340,7 +337729,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337354,8 +337742,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -337367,7 +337753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337490,6 +337875,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -337597,7 +337983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -337827,11 +338212,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -337844,49 +338227,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire", - "sourceId": "AAYWGY", - "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire", - "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Academic", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Batch auctions", - "dutch auctions", - "auctions", - "CoW Swap", - "research" - ], - "tags": [ - "Mechanism design", - "Intents", - "research", - "Intents", - "Mechanism design" - ], - "language": "en", - "speakers": [ - "andrea-canidio" - ], - "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731652200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -337985,6 +338327,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -338004,6 +338347,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -338017,6 +338361,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -338028,6 +338374,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -338229,7 +338576,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -338258,6 +338604,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -338487,9 +338834,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -338502,8 +338851,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire", + "sourceId": "AAYWGY", + "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire", + "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Academic", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Batch auctions", + "dutch auctions", + "auctions", + "CoW Swap", + "research" + ], + "tags": [ + "Mechanism design", + "Intents", + "research", + "Intents", + "Mechanism design" + ], + "language": "en", + "speakers": [ + "andrea-canidio" + ], + "eventId": "devcon-7", + "slot_start": 1731650400000, + "slot_end": 1731652200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -338630,7 +339020,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -338678,7 +339067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -338850,6 +339238,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -338893,7 +339282,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -339185,7 +339573,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -339198,59 +339585,12 @@ 0, 0, 0, - 2, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "farcaster-frames-building-embeddable-ethereum-apps", - "sourceId": "NPGET3", - "title": "Farcaster frames: building embeddable Ethereum apps", - "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "Social", - "farcaster", - "Developer Infrastructure", - "Social" - ], - "keywords": [ - "Farcaster" - ], - "duration": 5086, - "language": "en", - "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316", - "sources_youtubeId": "LnEpR575FRA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400800000, - "slot_end": 1731406200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M", - "resources_slides": null, - "speakers": [ - "horsefacts" - ] - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -339301,6 +339641,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -339348,6 +339689,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -339562,6 +339904,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -339593,7 +339936,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -339854,6 +340196,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -339866,12 +340209,59 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "farcaster-frames-building-embeddable-ethereum-apps", + "sourceId": "NPGET3", + "title": "Farcaster frames: building embeddable Ethereum apps", + "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "tags": [ + "Developer Infrastructure", + "Social", + "farcaster", + "Developer Infrastructure", + "Social" + ], + "keywords": [ + "Farcaster" + ], + "duration": 5086, + "language": "en", + "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316", + "sources_youtubeId": "LnEpR575FRA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731400800000, + "slot_end": 1731406200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M", + "resources_slides": null, + "speakers": [ + "horsefacts" + ] + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -340040,7 +340430,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -340166,7 +340555,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -340218,6 +340606,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -340319,7 +340708,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -340548,11 +340936,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -340565,59 +340951,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul", - "sourceId": "SSXAMG", - "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul", - "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Values", - "FOSS", - "Decentralization", - "culture", - "Decentralization", - "FOSS", - "Values" - ], - "keywords": [ - "Culture" - ], - "duration": 1584, - "language": "en", - "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc", - "sources_youtubeId": "sNPxhnznfEA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt", - "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw", - "resources_slides": null, - "speakers": [ - "eleftherios-diakomichalis" - ] - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -340717,6 +341055,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -340842,6 +341181,31 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -340959,7 +341323,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -340971,6 +341334,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -341199,9 +341563,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -341214,11 +341580,59 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul", + "sourceId": "SSXAMG", + "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul", + "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Values", + "FOSS", + "Decentralization", + "culture", + "Decentralization", + "FOSS", + "Values" + ], + "keywords": [ + "Culture" + ], + "duration": 1584, + "language": "en", + "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc", + "sources_youtubeId": "sNPxhnznfEA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt", + "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.", + "eventId": "devcon-7", + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw", + "resources_slides": null, + "speakers": [ + "eleftherios-diakomichalis" + ] + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -341453,7 +341867,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -341463,7 +341876,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -341564,6 +341976,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -341588,7 +342001,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -341685,7 +342097,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -341915,9 +342326,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -341930,36 +342339,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "financialization-in-games", - "sourceId": "EF3P9X", - "title": "Financialization in Games", - "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "n/a" - ], - "tags": [], - "language": "en", - "speakers": [ - "y77cao" - ], - "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731582300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc" - }, - "vector": [ 0, 0, 0, @@ -341972,7 +342351,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -342094,6 +342472,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -342103,6 +342482,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -342227,6 +342607,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -342308,7 +342689,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -342324,6 +342704,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -342552,7 +342934,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -342565,6 +342949,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "financialization-in-games", + "sourceId": "EF3P9X", + "title": "Financialization in Games", + "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "n/a" + ], + "tags": [], + "language": "en", + "speakers": [ + "y77cao" + ], + "eventId": "devcon-7", + "slot_start": 1731580800000, + "slot_end": 1731582300000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc" + }, + "vector": [ 0, 0, 0, @@ -342577,6 +342991,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -342914,6 +343329,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -343261,11 +343677,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -343278,32 +343692,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "find-yourself-on-the-mat", - "sourceId": "PYKTTA", - "title": "Find Yourself on the Mat", - "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", - "audience": "Hobby", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731404700000, - "slot_end": 1731407400000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ" - }, - "vector": [ 0, 0, 0, @@ -343313,7 +343701,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -343897,9 +344284,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -343912,6 +344301,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "find-yourself-on-the-mat", + "sourceId": "PYKTTA", + "title": "Find Yourself on the Mat", + "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "Beginner", + "audience": "Hobby", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731404700000, + "slot_end": 1731407400000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ" + }, + "vector": [ 0, 0, 0, @@ -343921,6 +344336,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -344607,7 +345023,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -344616,59 +345031,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "finding-bugs-42-tips-from-4-security-researchers", - "sourceId": "AZNENK", - "title": "Finding Bugs: 42 Tips from 4 Security Researchers", - "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.", - "track": "Security", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Education", - "Hacks", - "Smart Contract Security" - ], - "tags": [ - "Security", - "Auditing", - "Bug", - "Bounties", - "smart", - "contracts", - "Auditing", - "Bounties", - "Bug", - "Security" - ], - "language": "en", - "speakers": [ - "0xrajeev", - "joran-honig", - "nat-chin", - "tincho" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw" - }, - "vector": [ - 6, 0, 0, 0, @@ -344919,7 +345286,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -344944,7 +345310,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -345017,8 +345382,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -345271,6 +345634,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -345279,11 +345643,59 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "finding-bugs-42-tips-from-4-security-researchers", + "sourceId": "AZNENK", + "title": "Finding Bugs: 42 Tips from 4 Security Researchers", + "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.", + "track": "Security", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Education", + "Hacks", + "Smart Contract Security" + ], + "tags": [ + "Security", + "Auditing", + "Bug", + "Bounties", + "smart", + "contracts", + "Auditing", + "Bounties", + "Bug", + "Security" + ], + "language": "en", + "speakers": [ + "0xrajeev", + "joran-honig", + "nat-chin", + "tincho" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw" + }, + "vector": [ + 6, 0, 0, 0, @@ -345407,7 +345819,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -345536,6 +345947,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -345559,8 +345971,8 @@ 0, 0, 0, - 2, 0, + 6, 0, 0, 0, @@ -345634,6 +346046,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -345666,9 +346080,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -345682,7 +346093,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -345971,10 +346381,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -345986,48 +346394,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "finding-rough-consensus-on-issuance", - "sourceId": "GSKJK8", - "title": "Finding rough consensus on issuance", - "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Issuance", - "Lido", - "Ethereum" - ], - "tags": [ - "ethereum", - "Economics", - "Ethereum Roadmap", - "Politics" - ], - "language": "en", - "speakers": [ - "sacha" - ], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -346068,6 +346438,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -346219,6 +346590,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -346325,6 +346697,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -346338,6 +346713,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -346374,7 +346750,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -346627,8 +347002,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -346640,10 +347017,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "finding-rough-consensus-on-issuance", + "sourceId": "GSKJK8", + "title": "Finding rough consensus on issuance", + "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Issuance", + "Lido", + "Ethereum" + ], + "tags": [ + "ethereum", + "Economics", + "Ethereum Roadmap", + "Politics" + ], + "language": "en", + "speakers": [ + "sacha" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -346797,7 +347212,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -346956,7 +347370,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -346994,6 +347407,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -347070,7 +347484,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -347097,7 +347510,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -347326,62 +347738,18 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0, - 0 - ] - }, - { - "session": { - "id": "finding-your-place-in-crypto", - "sourceId": "CCVGE8", - "title": "Finding your place in crypto", - "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Personal", - "Human", - "Purpose" - ], - "tags": [ - "Governance", - "Decentralization", - "MEV", - "fairness", - "Coordination", - "Governance", - "Social" - ], - "language": "en", - "speakers": [ - "chris", - "davide-rezzoli" - ], - "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA" - }, - "vector": [ 0, 0, 0, @@ -347393,14 +347761,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -347472,6 +347832,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -347630,6 +347991,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -347734,8 +348096,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -347745,6 +348105,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -347771,6 +348132,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -347999,12 +348361,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -348012,6 +348376,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "finding-your-place-in-crypto", + "sourceId": "CCVGE8", + "title": "Finding your place in crypto", + "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Personal", + "Human", + "Purpose" + ], + "tags": [ + "Governance", + "Decentralization", + "MEV", + "fairness", + "Coordination", + "Governance", + "Social" + ], + "language": "en", + "speakers": [ + "chris", + "davide-rezzoli" + ], + "eventId": "devcon-7", + "slot_start": 1731582600000, + "slot_end": 1731583800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA" + }, + "vector": [ 0, 0, 0, @@ -348023,6 +348428,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -348123,7 +348529,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -348217,13 +348622,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -348276,7 +348679,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -348301,7 +348703,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -348370,6 +348771,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -348457,7 +348860,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -348685,7 +349087,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -348697,52 +349098,11 @@ 0, 0, 0, - 2, 0, 0, - 0 - ] - }, - { - "session": { - "id": "firefly-build-your-own-hardware-wallet", - "sourceId": "LMZKZS", - "title": "Firefly - Build your own hardware wallet", - "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.", - "track": "Developer Experience", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "DIY", - "Arduino" - ], - "tags": [ - "DevEx", - "Hacks", - "Hardware wallets", - "arduino", - "DevEx", - "Hacks", - "Hardware wallets" - ], - "language": "en", - "speakers": [ - "richard-moore" - ], - "eventId": "devcon-7", - "slot_start": 1731473400000, - "slot_end": 1731474000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -348802,6 +349162,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -348895,11 +349256,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -348952,6 +349315,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -348976,6 +349340,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -349069,7 +349434,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -349132,6 +349496,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -349359,6 +349724,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -349370,11 +349736,52 @@ 0, 0, 0, + 2, 0, 0, + 0 + ] + }, + { + "session": { + "id": "firefly-build-your-own-hardware-wallet", + "sourceId": "LMZKZS", + "title": "Firefly - Build your own hardware wallet", + "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "DIY", + "Arduino" + ], + "tags": [ + "DevEx", + "Hacks", + "Hardware wallets", + "arduino", + "DevEx", + "Hacks", + "Hardware wallets" + ], + "language": "en", + "speakers": [ + "richard-moore" + ], + "eventId": "devcon-7", + "slot_start": 1731473400000, + "slot_end": 1731474000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -349508,7 +349915,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -349704,6 +350110,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -349730,7 +350137,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -349815,8 +350221,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -350040,13 +350444,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -350057,45 +350459,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "folding-starks-with-the-mova-folding-scheme", - "sourceId": "J78CHZ", - "title": "Folding STARKs with the Mova folding scheme", - "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Folding", - "Post-Quantum" - ], - "tags": [ - "ZKP", - "Zero-Knowledge", - "STARK", - "post-quantum", - "STARK", - "Zero-Knowledge", - "ZKP" - ], - "language": "en", - "speakers": [ - "albert-garreta" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM" - }, - "vector": [ 0, 0, 0, @@ -350106,7 +350469,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -350189,6 +350551,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -350410,6 +350773,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -350450,7 +350814,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -350495,6 +350858,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -350718,11 +351083,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -350733,6 +351100,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "folding-starks-with-the-mova-folding-scheme", + "sourceId": "J78CHZ", + "title": "Folding STARKs with the Mova folding scheme", + "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Folding", + "Post-Quantum" + ], + "tags": [ + "ZKP", + "Zero-Knowledge", + "STARK", + "post-quantum", + "STARK", + "Zero-Knowledge", + "ZKP" + ], + "language": "en", + "speakers": [ + "albert-garreta" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM" + }, + "vector": [ 0, 0, 0, @@ -350743,6 +351149,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -350847,7 +351254,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -350910,7 +351316,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -351048,7 +351453,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -351091,6 +351495,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -351174,7 +351579,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -351400,9 +351804,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -351414,41 +351816,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "for-the-kingdom-mud-day-demo", - "sourceId": "FM3LCK", - "title": "For The Kingdom - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "fully", - "onchain", - "game" - ], - "tags": [ - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "tuyen-dinh" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731557100000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4" - }, - "vector": [ 0, 0, 0, @@ -351461,7 +351828,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -351528,6 +351894,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -351590,6 +351957,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -351727,6 +352095,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -351804,7 +352173,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -351853,6 +352221,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -352078,7 +352447,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -352090,6 +352461,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "for-the-kingdom-mud-day-demo", + "sourceId": "FM3LCK", + "title": "For The Kingdom - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "fully", + "onchain", + "game" + ], + "tags": [ + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "tuyen-dinh" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731557100000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4" + }, + "vector": [ 0, 0, 0, @@ -352102,6 +352508,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -352298,8 +352705,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -352448,6 +352853,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -352752,13 +353158,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -352767,46 +353171,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "fork-choice-enforced-inclusion-lists-focil", - "sourceId": "CDTX78", - "title": "Fork-Choice enforced Inclusion Lists (FOCIL)", - "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Censorship Resistance", - "Inclusion Lists", - "Mechanism Design" - ], - "tags": [ - "Design", - "mechanism" - ], - "language": "en", - "speakers": [ - "thomas-thiery" - ], - "eventId": "devcon-7", - "slot_start": 1731570000000, - "slot_end": 1731571800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -352981,6 +353349,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -353158,7 +353528,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -353434,11 +353803,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -353446,10 +353817,47 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "fork-choice-enforced-inclusion-lists-focil", + "sourceId": "CDTX78", + "title": "Fork-Choice enforced Inclusion Lists (FOCIL)", + "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Censorship Resistance", + "Inclusion Lists", + "Mechanism Design" + ], + "tags": [ + "Design", + "mechanism" + ], + "language": "en", + "speakers": [ + "thomas-thiery" + ], + "eventId": "devcon-7", + "slot_start": 1731570000000, + "slot_end": 1731571800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -353684,7 +354092,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -353804,6 +354211,51 @@ 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, @@ -353881,7 +354333,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -354103,12 +354554,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -354120,51 +354569,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions", - "sourceId": "KQCGWV", - "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions", - "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.", - "track": "Security", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "model checking", - "theorem proving" - ], - "tags": [ - "Security", - "Formal Verification", - "Testing", - "proving", - "theorem", - "Formal Verification", - "Security", - "Testing" - ], - "language": "en", - "speakers": [ - "david-pearce", - "igor-konnov", - "julian-sutherland", - "zoe-p" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731469500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8" - }, - "vector": [ - 6, - 0, 0, 0, 0, @@ -354214,7 +354618,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -354336,6 +354739,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -354345,7 +354749,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -354520,8 +354923,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -354535,6 +354936,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -354756,10 +355158,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -354771,6 +355175,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions", + "sourceId": "KQCGWV", + "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions", + "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.", + "track": "Security", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "model checking", + "theorem proving" + ], + "tags": [ + "Security", + "Formal Verification", + "Testing", + "proving", + "theorem", + "Formal Verification", + "Security", + "Testing" + ], + "language": "en", + "speakers": [ + "david-pearce", + "igor-konnov", + "julian-sutherland", + "zoe-p" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731469500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8" + }, + "vector": [ + 6, 0, 0, 0, @@ -354822,6 +355270,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -354902,7 +355351,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -354953,6 +355401,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -355017,7 +355466,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -355101,7 +355549,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -355130,6 +355577,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -355145,7 +355594,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -355243,7 +355691,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -355464,11 +355911,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -355481,51 +355926,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "fossify-yourself-for-privacy-and-security", - "sourceId": "TW7QGF", - "title": "FOSSify yourself for privacy and security", - "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": true, - "keywords": [ - "free software", - "degoogle", - "self hosting" - ], - "tags": [ - "Privacy", - "Security", - "self", - "hosting", - "Privacy", - "Security" - ], - "language": "en", - "speakers": [ - "mario-havel" - ], - "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731558600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -355556,6 +355961,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -355670,6 +356076,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -355753,6 +356160,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -355796,6 +356204,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -355827,7 +356236,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -355894,6 +356302,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -356114,9 +356523,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -356129,11 +356540,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "fossify-yourself-for-privacy-and-security", + "sourceId": "TW7QGF", + "title": "FOSSify yourself for privacy and security", + "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!", + "track": "Cypherpunk & Privacy", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": true, + "keywords": [ + "free software", + "degoogle", + "self hosting" + ], + "tags": [ + "Privacy", + "Security", + "self", + "hosting", + "Privacy", + "Security" + ], + "language": "en", + "speakers": [ + "mario-havel" + ], + "eventId": "devcon-7", + "slot_start": 1731553200000, + "slot_end": 1731558600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -356259,7 +356710,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -356376,7 +356826,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -356438,6 +356887,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -356601,8 +357051,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -356823,9 +357271,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -356838,55 +357284,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "fraud-proofs-war", - "sourceId": "UTTXWB", - "title": "Fraud proofs war", - "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "Optimistic rollups", - "Challenge period", - "Mechanism design", - "fraud", - "proof", - "Challenge period", - "Mechanism design", - "Optimistic rollups" - ], - "keywords": [ - "Fraud", - "proofs" - ], - "duration": 2519, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "tyouXHiQUmY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt", - "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs", - "resources_slides": null, - "speakers": [ - "luca-donno" - ] - }, - "vector": [ 0, 0, 0, @@ -356894,7 +357291,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -356926,6 +357322,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -357042,6 +357439,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -357246,7 +357644,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -357267,6 +357664,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -357487,7 +357886,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -357500,6 +357901,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "fraud-proofs-war", + "sourceId": "UTTXWB", + "title": "Fraud proofs war", + "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "Optimistic rollups", + "Challenge period", + "Mechanism design", + "fraud", + "proof", + "Challenge period", + "Mechanism design", + "Optimistic rollups" + ], + "keywords": [ + "Fraud", + "proofs" + ], + "duration": 2519, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "tyouXHiQUmY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt", + "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.", + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs", + "resources_slides": null, + "speakers": [ + "luca-donno" + ] + }, + "vector": [ 0, 0, 0, @@ -357507,6 +357957,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -357633,7 +358084,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -357694,7 +358144,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -357852,7 +358301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -357863,6 +358311,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -357970,8 +358421,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -358191,9 +358640,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -358205,52 +358652,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools", - "sourceId": "7TRTQW", - "title": "From Auctions to ZK: An Educational Tour of MPC Tools", - "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Confidential", - "computing" - ], - "tags": [ - "Zero-Knowledge", - "MPC", - "Homomorphic Encryption", - "confidentiality", - "computation", - "Homomorphic Encryption", - "MPC", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "aisling-connolly" - ], - "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731493200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -358294,6 +358700,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -358353,6 +358761,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -358377,7 +358786,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -358511,6 +358919,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -358627,6 +359037,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -358845,7 +359258,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -358857,11 +359272,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools", + "sourceId": "7TRTQW", + "title": "From Auctions to ZK: An Educational Tour of MPC Tools", + "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Confidential", + "computing" + ], + "tags": [ + "Zero-Knowledge", + "MPC", + "Homomorphic Encryption", + "confidentiality", + "computation", + "Homomorphic Encryption", + "MPC", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "aisling-connolly" + ], + "eventId": "devcon-7", + "slot_start": 1731491400000, + "slot_end": 1731493200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -358989,6 +359445,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -358996,7 +359453,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -359073,8 +359529,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -359330,8 +359784,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -359546,7 +359998,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -359554,7 +360005,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -359563,45 +360013,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers", - "sourceId": "LT8BTE", - "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers", - "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Performance", - "Optimization" - ], - "tags": [ - "Layer 2s", - "ZK-EVMs", - "Open Source Software", - "optimization", - "Layer 2s", - "Open Source Software", - "ZK-EVMs" - ], - "language": "en", - "speakers": [ - "leo-jeong" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI" - }, - "vector": [ 0, 0, 0, @@ -359612,7 +360023,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -359657,6 +360067,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -359733,6 +360144,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -359962,7 +360375,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -359989,6 +360401,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -360203,6 +360617,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -360210,6 +360625,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -360218,6 +360634,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers", + "sourceId": "LT8BTE", + "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers", + "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Performance", + "Optimization" + ], + "tags": [ + "Layer 2s", + "ZK-EVMs", + "Open Source Software", + "optimization", + "Layer 2s", + "Open Source Software", + "ZK-EVMs" + ], + "language": "en", + "speakers": [ + "leo-jeong" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI" + }, + "vector": [ 0, 0, 0, @@ -360228,6 +360683,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -360407,7 +360863,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -360439,7 +360894,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -360581,6 +361035,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -360689,8 +361144,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -360903,12 +361356,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -360920,67 +361371,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution", - "sourceId": "ZBC9ZM", - "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution", - "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Business", - "featured": false, - "doNotRecord": false, - "tags": [ - "Sustainability", - "Ethereum for Good", - "Public good", - "real-world", - "deployment", - "Ethereum for Good", - "Public good", - "Sustainability" - ], - "keywords": [ - "Real-World", - "Deployment" - ], - "duration": 974, - "language": "en", - "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384", - "sources_youtubeId": "0dSz0CN6bI8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt", - "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which", - "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731410400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc", - "resources_slides": null, - "speakers": [ - "david-casey", - "arun-maharajan", - "mansi" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -361052,9 +361448,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -361088,6 +361482,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -361119,6 +361514,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -361332,7 +361728,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -361369,6 +361764,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -361581,10 +361978,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -361596,12 +361995,64 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution", + "sourceId": "ZBC9ZM", + "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution", + "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Business", + "featured": false, + "doNotRecord": false, + "tags": [ + "Sustainability", + "Ethereum for Good", + "Public good", + "real-world", + "deployment", + "Ethereum for Good", + "Public good", + "Sustainability" + ], + "keywords": [ + "Real-World", + "Deployment" + ], + "duration": 974, + "language": "en", + "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384", + "sources_youtubeId": "0dSz0CN6bI8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt", + "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which", + "eventId": "devcon-7", + "slot_start": 1731409200000, + "slot_end": 1731410400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc", + "resources_slides": null, + "speakers": [ + "david-casey", + "arun-maharajan", + "mansi" + ] + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -361677,7 +362128,9 @@ 0, 0, 0, + 6, 0, + 6, 0, 0, 0, @@ -361819,7 +362272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -361836,7 +362288,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -361893,7 +362344,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -361959,6 +362409,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -362060,8 +362511,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -362274,12 +362723,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -362289,42 +362736,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-mpc-wallets-to-smart-contract-accounts", - "sourceId": "XMTH8N", - "title": "From MPC Wallets to Smart Contract Accounts", - "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EIP-7702" - ], - "tags": [ - "MPC", - "Account Abstraction", - "eip-7702", - "Account Abstraction", - "MPC" - ], - "language": "en", - "speakers": [ - "phuc-thai" - ], - "eventId": "devcon-7", - "slot_start": 1731559200000, - "slot_end": 1731559800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ" - }, - "vector": [ 0, 0, 0, @@ -362333,7 +362744,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -362488,6 +362898,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -362504,6 +362915,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -362560,6 +362972,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -362687,7 +363100,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -362727,6 +363139,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -362939,10 +363353,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -362952,6 +363368,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-mpc-wallets-to-smart-contract-accounts", + "sourceId": "XMTH8N", + "title": "From MPC Wallets to Smart Contract Accounts", + "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EIP-7702" + ], + "tags": [ + "MPC", + "Account Abstraction", + "eip-7702", + "Account Abstraction", + "MPC" + ], + "language": "en", + "speakers": [ + "phuc-thai" + ], + "eventId": "devcon-7", + "slot_start": 1731559200000, + "slot_end": 1731559800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ" + }, + "vector": [ 0, 0, 0, @@ -362960,6 +363412,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -363115,7 +363568,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -363153,7 +363605,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -363317,6 +363768,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -363416,7 +363868,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -363626,7 +364077,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -363634,7 +364084,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -363643,48 +364092,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum", - "sourceId": "CGTBC7", - "title": "From Nanoseconds to Decades: The Timescales of Ethereum", - "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Fun", - "Data" - ], - "tags": [ - "Core Protocol", - "data", - "fun", - "Core", - "Protocol" - ], - "language": "en", - "speakers": [ - "jannik-luhn" - ], - "eventId": "devcon-7", - "slot_start": 1731469200000, - "slot_end": 1731469800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -363787,6 +364198,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -363824,6 +364236,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -364043,7 +364456,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -364087,6 +364499,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -364296,6 +364709,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -364303,6 +364717,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -364311,10 +364726,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum", + "sourceId": "CGTBC7", + "title": "From Nanoseconds to Decades: The Timescales of Ethereum", + "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Fun", + "Data" + ], + "tags": [ + "Core Protocol", + "data", + "fun", + "Core", + "Protocol" + ], + "language": "en", + "speakers": [ + "jannik-luhn" + ], + "eventId": "devcon-7", + "slot_start": 1731469200000, + "slot_end": 1731469800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -364438,7 +364891,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -364676,6 +365128,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -364724,13 +365177,10 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -364772,7 +365222,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -364983,14 +365432,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -364998,52 +365445,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-packets-to-privacy-understanding-and-evolving-network-security", - "sourceId": "XYRFXT", - "title": "From Packets to Privacy: Understanding and Evolving Network Security", - "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Mixnet", - "VPN" - ], - "tags": [ - "Privacy", - "Anonymity", - "Censorship Resistance", - "vpn", - "Anonymity", - "Censorship Resistance", - "Privacy" - ], - "language": "en", - "speakers": [ - "max-hampshire", - "med-amor" - ], - "eventId": "devcon-7", - "slot_start": 1731496200000, - "slot_end": 1731496800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -365119,6 +365525,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -365402,8 +365809,27 @@ 0, 0, 0, - 6, - 6, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -365433,6 +365859,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -365642,12 +366070,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -365655,11 +366085,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-packets-to-privacy-understanding-and-evolving-network-security", + "sourceId": "XYRFXT", + "title": "From Packets to Privacy: Understanding and Evolving Network Security", + "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Mixnet", + "VPN" + ], + "tags": [ + "Privacy", + "Anonymity", + "Censorship Resistance", + "vpn", + "Anonymity", + "Censorship Resistance", + "Privacy" + ], + "language": "en", + "speakers": [ + "max-hampshire", + "med-amor" + ], + "eventId": "devcon-7", + "slot_start": 1731496200000, + "slot_end": 1731496800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -365803,7 +366274,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -365894,7 +366364,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -365925,7 +366394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -366023,6 +366491,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -366131,7 +366601,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -366341,13 +366810,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -366356,50 +366823,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond", - "sourceId": "EVSLDH", - "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond", - "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "PeerDAS", - "FullDAS" - ], - "tags": [ - "Danksharding", - "DAS", - "Scalability", - "fulldas", - "Danksharding", - "DAS", - "Scalability" - ], - "language": "en", - "speakers": [ - "csaba-kiraly" - ], - "eventId": "devcon-7", - "slot_start": 1731575400000, - "slot_end": 1731577200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -366467,6 +366894,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -366557,6 +366985,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -366587,6 +367016,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -366761,7 +367191,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -366793,6 +367222,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -367002,11 +367432,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -367015,10 +367447,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond", + "sourceId": "EVSLDH", + "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond", + "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "PeerDAS", + "FullDAS" + ], + "tags": [ + "Danksharding", + "DAS", + "Scalability", + "fulldas", + "Danksharding", + "DAS", + "Scalability" + ], + "language": "en", + "speakers": [ + "csaba-kiraly" + ], + "eventId": "devcon-7", + "slot_start": 1731575400000, + "slot_end": 1731577200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -367199,7 +367671,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -367274,7 +367745,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -367384,6 +367854,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -367489,8 +367960,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -367699,9 +368168,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -367713,48 +368180,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "from-web2-security-with-love", - "sourceId": "VYEKSS", - "title": "From Web2 Security With Love", - "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.", - "track": "Security", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Intelligence" - ], - "tags": [ - "Security", - "Hacks", - "intelligence", - "Hacks", - "Security" - ], - "language": "en", - "speakers": [ - "joe-dobson" - ], - "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI" - }, - "vector": [ - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -367869,6 +368294,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -367943,6 +368369,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -368116,7 +368543,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -368158,6 +368584,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -368366,7 +368794,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -368378,6 +368808,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "from-web2-security-with-love", + "sourceId": "VYEKSS", + "title": "From Web2 Security With Love", + "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.", + "track": "Security", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Intelligence" + ], + "tags": [ + "Security", + "Hacks", + "intelligence", + "Hacks", + "Security" + ], + "language": "en", + "speakers": [ + "joe-dobson" + ], + "eventId": "devcon-7", + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI" + }, + "vector": [ + 6, 0, 0, 0, @@ -368488,7 +368955,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -368740,15 +369206,14 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -369052,80 +369517,6 @@ 0, 0, 0, - 2, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "future-of-onchain-credit-scoring-for-farmers", - "sourceId": "BBEDYL", - "title": "Future of Onchain Credit Scoring for Farmers", - "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": true, - "keywords": [ - "Agriculture" - ], - "tags": [ - "Identity", - "agriculture", - "Identity" - ], - "language": "en", - "speakers": [ - "eddie-kago" - ], - "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731580800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78" - }, - "vector": [ - 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, @@ -369196,6 +369587,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -369447,8 +369839,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -369469,7 +369863,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -369758,7 +370151,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -369771,12 +370166,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "future-of-onchain-credit-scoring-for-farmers", + "sourceId": "BBEDYL", + "title": "Future of Onchain Credit Scoring for Farmers", + "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": true, + "keywords": [ + "Agriculture" + ], + "tags": [ + "Identity", + "agriculture", + "Identity" + ], + "language": "en", + "speakers": [ + "eddie-kago" + ], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731580800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -369889,7 +370319,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -370141,6 +370570,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -370197,7 +370627,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -370402,11 +370831,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -370419,48 +370846,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "fuzzing-zero-knowledge-infrastructure", - "sourceId": "QYWS83", - "title": "Fuzzing Zero-Knowledge Infrastructure", - "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Metamorphic", - "Testing" - ], - "tags": [ - "ZKP", - "Zero-Knowledge", - "Security", - "Fuzzing", - "Testing", - "metamorphic", - "Fuzzing", - "Security", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "valentin-wustholz" - ], - "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U" - }, - "vector": [ - 6, 0, 0, 0, @@ -370607,6 +370992,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -370829,7 +371215,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -370915,6 +371300,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -371119,9 +371505,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -371134,6 +371522,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "fuzzing-zero-knowledge-infrastructure", + "sourceId": "QYWS83", + "title": "Fuzzing Zero-Knowledge Infrastructure", + "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Metamorphic", + "Testing" + ], + "tags": [ + "ZKP", + "Zero-Knowledge", + "Security", + "Fuzzing", + "Testing", + "metamorphic", + "Fuzzing", + "Security", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "valentin-wustholz" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U" + }, + "vector": [ + 6, 0, 0, 0, @@ -371199,8 +371629,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -371211,7 +371639,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -371274,7 +371701,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -371442,7 +371868,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -371509,6 +371934,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -371557,7 +371985,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -371761,12 +372188,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -371778,52 +372203,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "gas-limit-and-block-execution", - "sourceId": "LPLSDD", - "title": "Gas Limit and Block Execution", - "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "keywords": [ - "gas limit", - "block execution", - "Execution Layer" - ], - "tags": [ - "Core Protocol", - "Layer 1", - "Protocol Design", - "execution", - "layer", - "Core Protocol", - "Layer 1", - "Protocol Design" - ], - "language": "en", - "speakers": [ - "marekm25" - ], - "eventId": "devcon-7", - "slot_start": 1731566400000, - "slot_end": 1731568200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -371923,6 +372306,10 @@ 0, 0, 0, + 6, + 6, + 0, + 0, 0, 0, 0, @@ -371931,6 +372318,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -371993,6 +372381,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -372160,6 +372549,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -372189,7 +372587,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -372267,6 +372664,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -372469,10 +372868,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -372484,10 +372885,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "gas-limit-and-block-execution", + "sourceId": "LPLSDD", + "title": "Gas Limit and Block Execution", + "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "keywords": [ + "gas limit", + "block execution", + "Execution Layer" + ], + "tags": [ + "Core Protocol", + "Layer 1", + "Protocol Design", + "execution", + "layer", + "Core Protocol", + "Layer 1", + "Protocol Design" + ], + "language": "en", + "speakers": [ + "marekm25" + ], + "eventId": "devcon-7", + "slot_start": 1731566400000, + "slot_end": 1731568200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -372573,11 +373016,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, @@ -372604,7 +373045,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -372755,7 +373195,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -372859,6 +373298,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -372917,7 +373357,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -373120,7 +373559,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -373130,51 +373568,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups", - "sourceId": "KXFHXJ", - "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups", - "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Metering" - ], - "tags": [ - "Gas", - "Appchains", - "Mechanism design", - "metering", - "Appchains", - "Gas", - "Mechanism design" - ], - "language": "en", - "speakers": [ - "felipe-argento" - ], - "eventId": "devcon-7", - "slot_start": 1731583200000, - "slot_end": 1731583800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU" - }, - "vector": [ 0, 0, 0, @@ -373182,7 +373581,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -373286,9 +373684,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, 0, 0, 0, @@ -373315,6 +373715,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -373465,6 +373866,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -373546,7 +373948,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -373627,6 +374028,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -373829,6 +374231,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -373838,12 +374241,51 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups", + "sourceId": "KXFHXJ", + "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups", + "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Metering" + ], + "tags": [ + "Gas", + "Appchains", + "Mechanism design", + "metering", + "Appchains", + "Gas", + "Mechanism design" + ], + "language": "en", + "speakers": [ + "felipe-argento" + ], + "eventId": "devcon-7", + "slot_start": 1731583200000, + "slot_end": 1731583800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU" + }, + "vector": [ 0, 0, 0, @@ -373851,6 +374293,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -373921,7 +374364,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -374144,7 +374586,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -374218,6 +374659,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -374243,7 +374685,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -374274,7 +374715,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -374479,9 +374919,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -374493,54 +374931,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "giga-staking-for-school-connectivity", - "sourceId": "ZU3AEJ", - "title": "Giga: Staking for school connectivity", - "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "connectivity", - "schools", - "social impact" - ], - "tags": [ - "Staking", - "Sustainability", - "Ethereum for Good", - "Social", - "impact", - "Ethereum for Good", - "Staking", - "Sustainability" - ], - "language": "en", - "speakers": [ - "gerben-kijne" - ], - "eventId": "devcon-7", - "slot_start": 1731577200000, - "slot_end": 1731577800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -374640,6 +375036,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -374862,6 +375259,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -374906,7 +375304,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -374961,6 +375358,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -374991,6 +375389,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -375195,7 +375594,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -375207,12 +375608,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "giga-staking-for-school-connectivity", + "sourceId": "ZU3AEJ", + "title": "Giga: Staking for school connectivity", + "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "connectivity", + "schools", + "social impact" + ], + "tags": [ + "Staking", + "Sustainability", + "Ethereum for Good", + "Social", + "impact", + "Ethereum for Good", + "Staking", + "Sustainability" + ], + "language": "en", + "speakers": [ + "gerben-kijne" + ], + "eventId": "devcon-7", + "slot_start": 1731577200000, + "slot_end": 1731577800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -375399,10 +375842,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -375453,7 +375894,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -375539,7 +375979,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -375584,6 +376023,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -375623,7 +376063,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -375837,14 +376276,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -375852,49 +376289,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "giga-undepin-to-connect-every-school-in-the-world", - "sourceId": "JXH3T3", - "title": "Giga: (UN)DePIN to connect every school in the world", - "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Connectivity", - "real world digital assets", - "" - ], - "tags": [ - "DePIN", - "Ethereum for Good", - "Politics" - ], - "language": "en", - "speakers": [ - "christopher-fabian" - ], - "eventId": "devcon-7", - "slot_start": 1731576000000, - "slot_end": 1731577200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -376118,8 +376518,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -376170,6 +376572,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -376255,13 +376658,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -376339,6 +376742,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -376552,12 +376956,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -376565,12 +376971,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "giga-undepin-to-connect-every-school-in-the-world", + "sourceId": "JXH3T3", + "title": "Giga: (UN)DePIN to connect every school in the world", + "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Connectivity", + "real world digital assets", + "" + ], + "tags": [ + "DePIN", + "Ethereum for Good", + "Politics" + ], + "language": "en", + "speakers": [ + "christopher-fabian" + ], + "eventId": "devcon-7", + "slot_start": 1731576000000, + "slot_end": 1731577200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -376649,7 +377092,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -376753,7 +377195,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -376941,6 +377382,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -376962,7 +377404,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -377191,14 +377632,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -377206,36 +377645,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing", - "sourceId": "PZACPB", - "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "tom-cirrito-phd" - ], - "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731570300000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -377362,6 +377772,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -377464,6 +377876,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -377608,7 +378021,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -377673,6 +378085,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -377898,12 +378314,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -377911,7 +378329,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing", + "sourceId": "PZACPB", + "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "tom-cirrito-phd" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731570300000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -378286,6 +378733,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -378536,10 +378984,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -378552,53 +378998,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance", - "sourceId": "ZKNSAL", - "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance", - "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Vote Escrow", - "Funding Allocation", - "Voter Analytics" - ], - "tags": [ - "Permissionless", - "Coordination", - "Governance", - "Decentralization", - "Game Theory", - "Tokenomics", - "voting", - "analytics", - "Coordination", - "Decentralization", - "Game Theory", - "Governance", - "Permissionless", - "Tokenomics" - ], - "language": "en", - "speakers": [ - "tanisha-katara" - ], - "eventId": "devcon-7", - "slot_start": 1731489000000, - "slot_end": 1731489600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE" - }, - "vector": [ 0, 0, 0, @@ -378610,7 +379009,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -378974,7 +379372,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -379266,8 +379663,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -379280,6 +379679,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance", + "sourceId": "ZKNSAL", + "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance", + "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Vote Escrow", + "Funding Allocation", + "Voter Analytics" + ], + "tags": [ + "Permissionless", + "Coordination", + "Governance", + "Decentralization", + "Game Theory", + "Tokenomics", + "voting", + "analytics", + "Coordination", + "Decentralization", + "Game Theory", + "Governance", + "Permissionless", + "Tokenomics" + ], + "language": "en", + "speakers": [ + "tanisha-katara" + ], + "eventId": "devcon-7", + "slot_start": 1731489000000, + "slot_end": 1731489600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE" + }, + "vector": [ 0, 0, 0, @@ -379291,6 +379737,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -379346,7 +379793,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -379382,7 +379828,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379411,7 +379856,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379434,13 +379878,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -379493,7 +379935,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379530,7 +379971,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379663,6 +380103,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -379699,7 +380140,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -379903,56 +380343,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "grandine-on-windows", - "sourceId": "SUTU99", - "title": "Grandine on Windows", - "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.", - "track": "[CLS] EPF Day", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Rust", - "Client", - "Engineering" - ], - "tags": [ - "Best Practices", - "Core Protocol", - "Languages" - ], - "language": "en", - "speakers": [ - "jin-mingjian" - ], - "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731482100000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0" - }, - "vector": [ 0, 0, 0, @@ -379968,11 +380365,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -380085,6 +380477,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -380120,6 +380513,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380148,6 +380542,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380170,11 +380565,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -380227,6 +380624,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380263,6 +380661,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380329,7 +380728,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -380432,6 +380830,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -380635,10 +381034,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -380647,6 +381048,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "grandine-on-windows", + "sourceId": "SUTU99", + "title": "Grandine on Windows", + "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.", + "track": "[CLS] EPF Day", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Rust", + "Client", + "Engineering" + ], + "tags": [ + "Best Practices", + "Core Protocol", + "Languages" + ], + "language": "en", + "speakers": [ + "jin-mingjian" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731482100000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0" + }, + "vector": [ 0, 0, 0, @@ -380662,6 +381099,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -380711,7 +381149,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -380723,7 +381160,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -380789,7 +381225,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -381027,6 +381462,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -381256,9 +381692,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -381271,51 +381705,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "grapheneos-a-brief-introduction-to-private-and-secure-android", - "sourceId": "QK3ZTL", - "title": "GrapheneOS: a brief introduction to private and secure Android", - "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": true, - "keywords": [ - "Android" - ], - "tags": [ - "Privacy", - "Security", - "Mobile", - "android", - "Mobile", - "Privacy", - "Security" - ], - "language": "en", - "speakers": [ - "hulk", - "maade" - ], - "eventId": "devcon-7", - "slot_start": 1731486000000, - "slot_end": 1731487800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -381452,6 +381846,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -381463,6 +381858,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -381528,6 +381924,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -381687,8 +382084,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -381996,7 +382391,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -382009,11 +382406,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "grapheneos-a-brief-introduction-to-private-and-secure-android", + "sourceId": "QK3ZTL", + "title": "GrapheneOS: a brief introduction to private and secure Android", + "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": true, + "keywords": [ + "Android" + ], + "tags": [ + "Privacy", + "Security", + "Mobile", + "android", + "Mobile", + "Privacy", + "Security" + ], + "language": "en", + "speakers": [ + "hulk", + "maade" + ], + "eventId": "devcon-7", + "slot_start": 1731486000000, + "slot_end": 1731487800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -382049,7 +382486,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -382072,7 +382508,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -382166,7 +382601,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -382390,6 +382824,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -382411,7 +382847,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -382613,9 +383048,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -382627,41 +383060,6 @@ 0, 0, 0, - 0, - 0 - ] - }, - { - "session": { - "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items", - "sourceId": "AZCYRS", - "title": "Growing The Biomes GDP Using Digital Matter & Smart Items", - "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "dhrumil-shah", - "dhvani-patel" - ], - "eventId": "devcon-7", - "slot_start": 1731567000000, - "slot_end": 1731568500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4" - }, - "vector": [ 0, 0, 0, @@ -382674,8 +383072,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -382738,9 +383134,6 @@ 0, 0, 0, - 6, - 6, - 0, 0, 0, 0, @@ -382795,6 +383188,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -382817,6 +383211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -382910,6 +383305,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -383154,6 +383550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -383355,7 +383752,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -383368,6 +383767,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items", + "sourceId": "AZCYRS", + "title": "Growing The Biomes GDP Using Digital Matter & Smart Items", + "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "dhrumil-shah", + "dhvani-patel" + ], + "eventId": "devcon-7", + "slot_start": 1731567000000, + "slot_end": 1731568500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4" + }, + "vector": [ 0, 0, 0, @@ -383380,6 +383813,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -383444,6 +383878,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -383511,8 +383947,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -383965,9 +384399,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -383980,45 +384412,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hacking-thai-beats-cities-and-dances", - "sourceId": "NM8B9E", - "title": "Hacking Thai Beats, Cities & Dances", - "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Art", - "FOSS", - "Live Coding" - ], - "language": "en", - "speakers": [ - "phoomparin-mano" - ], - "eventId": "devcon-7", - "slot_start": 1731552900000, - "slot_end": 1731554100000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -384255,6 +384654,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -384391,7 +384792,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -384708,7 +385108,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -384721,12 +385123,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hacking-thai-beats-cities-and-dances", + "sourceId": "NM8B9E", + "title": "Hacking Thai Beats, Cities & Dances", + "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Art", + "FOSS", + "Live Coding" + ], + "language": "en", + "speakers": [ + "phoomparin-mano" + ], + "eventId": "devcon-7", + "slot_start": 1731552900000, + "slot_end": 1731554100000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -384859,7 +385294,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -384867,7 +385301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -385085,7 +385518,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -385104,6 +385536,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -385315,9 +385748,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -385330,44 +385761,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hallucinated-servers-another-prog-crypto-chip", - "sourceId": "DYJ88A", - "title": "hallucinated servers another prog crypto chip", - "description": "hallucinated servers another prog crypto chip\r\n\r\nNot sure about the rest ;)", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Cyprography", - "fhe", - "mpc" - ], - "tags": [ - "Cryptography", - "MPC", - "fhe", - "Cryptography", - "MPC" - ], - "language": "en", - "speakers": [ - "brian-lawrence" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo" - }, - "vector": [ 0, 0, 0, @@ -385378,7 +385771,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -385614,6 +386006,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -385621,6 +386014,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -385748,7 +386142,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -385839,6 +386232,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -386068,7 +386462,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -386081,6 +386477,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hallucinated-servers-another-prog-crypto-chip", + "sourceId": "DYJ88A", + "title": "hallucinated servers another prog crypto chip", + "description": "hallucinated servers another prog crypto chip\r\n\r\nNot sure about the rest ;)", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Cyprography", + "fhe", + "mpc" + ], + "tags": [ + "Cryptography", + "MPC", + "fhe", + "Cryptography", + "MPC" + ], + "language": "en", + "speakers": [ + "brian-lawrence" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo" + }, + "vector": [ 0, 0, 0, @@ -386091,6 +386525,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -386120,7 +386555,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -386196,7 +386630,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -386464,13 +386897,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -386671,9 +387104,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -386686,34 +387117,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hardening-mobile-operating-systems-for-enhanced-privacy", - "sourceId": "DRKWGV", - "title": "Hardening Mobile Operating Systems for Enhanced Privacy", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731576000000, - "slot_end": 1731576900000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1d2aapQyYzhgjOalAv-TJnnfo0oZ8Q-k-T4Lsok_kqbY" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -386867,6 +387271,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -386942,6 +387347,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -387215,6 +387621,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -387415,7 +387822,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -387428,7 +387837,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hardening-mobile-operating-systems-for-enhanced-privacy", + "sourceId": "DRKWGV", + "title": "Hardening Mobile Operating Systems for Enhanced Privacy", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731576000000, + "slot_end": 1731576900000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1d2aapQyYzhgjOalAv-TJnnfo0oZ8Q-k-T4Lsok_kqbY" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -388014,10 +388450,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -388030,59 +388464,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hardening-the-commons", - "sourceId": "BMTVJK", - "title": "Hardening the Commons", - "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.", - "track": "Coordination", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Impact", - "Commons", - "Adoption" - ], - "tags": [ - "adoption", - "Censorship Resistance", - "Coordination", - "Solarpunk" - ], - "language": "en", - "speakers": [ - "tim-beiko", - "venkatesh-rao" - ], - "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731497400000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -388258,7 +388639,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -388449,7 +388829,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -388790,8 +389169,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -388804,6 +389185,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hardening-the-commons", + "sourceId": "BMTVJK", + "title": "Hardening the Commons", + "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.", + "track": "Coordination", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Impact", + "Commons", + "Adoption" + ], + "tags": [ + "adoption", + "Censorship Resistance", + "Coordination", + "Solarpunk" + ], + "language": "en", + "speakers": [ + "tim-beiko", + "venkatesh-rao" + ], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731497400000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs" + }, + "vector": [ 0, 0, 0, @@ -388815,6 +389234,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -388932,7 +389352,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -388955,17 +389374,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -388998,6 +389414,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -389189,6 +389606,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -389371,14 +389789,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -389386,49 +389802,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hardhat-3-preview-overhauled-and-rust-powered", - "sourceId": "QZYQYE", - "title": "Hardhat 3 Preview: Overhauled & Rust-Powered", - "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Hardhat", - "Solidity" - ], - "tags": [ - "Developer Infrastructure", - "Tooling", - "DevEx", - "solidity", - "Developer Infrastructure", - "DevEx", - "Tooling" - ], - "language": "en", - "speakers": [ - "patricio-palladino" - ], - "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -389715,6 +390091,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -389737,14 +390114,17 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -389807,26 +390187,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -390170,12 +390530,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -390183,10 +390545,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hardhat-3-preview-overhauled-and-rust-powered", + "sourceId": "QZYQYE", + "title": "Hardhat 3 Preview: Overhauled & Rust-Powered", + "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Hardhat", + "Solidity" + ], + "tags": [ + "Developer Infrastructure", + "Tooling", + "DevEx", + "solidity", + "Developer Infrastructure", + "DevEx", + "Tooling" + ], + "language": "en", + "speakers": [ + "patricio-palladino" + ], + "eventId": "devcon-7", + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw" + }, + "vector": [ 0, 0, - 2, 0, + 6, 0, 0, 0, @@ -390194,7 +390595,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -390218,7 +390618,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -390528,10 +390927,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -390573,6 +390968,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -390726,13 +391122,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -390743,43 +391137,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hardware-security-from-sand-to-stone", - "sourceId": "UZDFEK", - "title": "Hardware Security: From Sand to Stone", - "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "TEE", - "Hardware Trojans" - ], - "tags": [ - "Decentralization", - "Hardware wallets", - "Security" - ], - "language": "en", - "speakers": [ - "quintus-kilbourn" - ], - "eventId": "devcon-7", - "slot_start": 1731575400000, - "slot_end": 1731576000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -390990,6 +391348,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -390998,6 +391357,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -391021,6 +391381,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -391161,7 +391522,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -391331,6 +391691,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -391517,7 +391878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -391529,11 +391889,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -391544,7 +391906,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hardware-security-from-sand-to-stone", + "sourceId": "UZDFEK", + "title": "Hardware Security: From Sand to Stone", + "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "TEE", + "Hardware Trojans" + ], + "tags": [ + "Decentralization", + "Hardware wallets", + "Security" + ], + "language": "en", + "speakers": [ + "quintus-kilbourn" + ], + "eventId": "devcon-7", + "slot_start": 1731575400000, + "slot_end": 1731576000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -391619,7 +392017,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -391854,7 +392251,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -391930,6 +392326,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -392079,11 +392476,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -392096,32 +392491,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "harry-p", - "sourceId": "LXJJDW", - "title": "Harry P", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE" - }, - "vector": [ 0, 0, 0, @@ -392131,7 +392500,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -392316,6 +392684,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -392417,6 +392786,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -392651,6 +393021,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -392875,9 +393246,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -392890,6 +393263,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "harry-p", + "sourceId": "LXJJDW", + "title": "Harry P", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE" + }, + "vector": [ 0, 0, 0, @@ -392899,6 +393298,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -393424,10 +393824,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -393440,44 +393838,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution", - "sourceId": "YQPADR", - "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution", - "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Symbolic Execution", - "EVM" - ], - "tags": [ - "Security", - "Fuzzing", - "EVM", - "Fuzzing", - "Security" - ], - "language": "en", - "speakers": [ - "mate-soos" - ], - "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731562200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8" - }, - "vector": [ - 6, 0, 0, 0, @@ -393861,7 +394221,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -394216,8 +394575,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -394238,8 +394595,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -394252,6 +394611,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution", + "sourceId": "YQPADR", + "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution", + "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Symbolic Execution", + "EVM" + ], + "tags": [ + "Security", + "Fuzzing", + "EVM", + "Fuzzing", + "Security" + ], + "language": "en", + "speakers": [ + "mate-soos" + ], + "eventId": "devcon-7", + "slot_start": 1731560400000, + "slot_end": 1731562200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8" + }, + "vector": [ + 6, 0, 0, 0, @@ -394425,7 +394822,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -394638,6 +395034,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -394778,11 +395177,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -394795,55 +395192,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders", - "sourceId": "RKR9EC", - "title": "How crypto is used in Africa today? Hear from leading builders", - "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Mass adoption", - "payment", - "P2P" - ], - "tags": [ - "Use Cases", - "Remittance", - "Ethereum for Good", - "p2p", - "Ethereum for Good", - "Remittance", - "Use Cases" - ], - "language": "en", - "speakers": [ - "yoseph-ayele", - "yele-bademosi", - "david-nandwa" - ], - "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731654000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -395037,6 +395391,11 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -395222,9 +395581,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -395244,6 +395600,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -395593,9 +395953,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -395608,12 +395970,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders", + "sourceId": "RKR9EC", + "title": "How crypto is used in Africa today? Hear from leading builders", + "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Mass adoption", + "payment", + "P2P" + ], + "tags": [ + "Use Cases", + "Remittance", + "Ethereum for Good", + "p2p", + "Ethereum for Good", + "Remittance", + "Use Cases" + ], + "language": "en", + "speakers": [ + "yoseph-ayele", + "yele-bademosi", + "david-nandwa" + ], + "eventId": "devcon-7", + "slot_start": 1731650400000, + "slot_end": 1731654000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -395655,7 +396060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395702,7 +396106,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395875,7 +396278,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395941,7 +396343,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -395998,6 +396399,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -396140,14 +396544,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -396155,51 +396557,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-crypto-solves-real-world-mev", - "sourceId": "WQBBFR", - "title": "How Crypto Solves Real World MEV", - "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Trusted", - "Execution", - "Environments" - ], - "tags": [ - "Use cases of cryptography", - "Use Cases", - "Environment", - "Mechanism design", - "trusted", - "execution", - "Mechanism design", - "Use Cases", - "Use cases of cryptography" - ], - "language": "en", - "speakers": [ - "matt-stephenson" - ], - "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -396475,6 +396834,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396521,6 +396881,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396585,7 +396946,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -396694,6 +397054,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396759,6 +397120,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396943,7 +397305,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -396958,6 +397319,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -396972,6 +397334,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-crypto-solves-real-world-mev", + "sourceId": "WQBBFR", + "title": "How Crypto Solves Real World MEV", + "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Trusted", + "Execution", + "Environments" + ], + "tags": [ + "Use cases of cryptography", + "Use Cases", + "Environment", + "Mechanism design", + "trusted", + "execution", + "Mechanism design", + "Use Cases", + "Use cases of cryptography" + ], + "language": "en", + "speakers": [ + "matt-stephenson" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg" + }, + "vector": [ + 0, + 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -397015,7 +397425,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -397108,7 +397517,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -397133,7 +397541,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -397302,7 +397709,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -397360,6 +397766,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -397498,12 +397905,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -397515,50 +397920,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr", - "sourceId": "G7AHS9", - "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR", - "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EVM", - "Hardhat", - "Optimism" - ], - "tags": [ - "Layer 2s", - "Tooling", - "DevEx", - "optimism", - "DevEx", - "Layer 2s", - "Tooling" - ], - "language": "en", - "speakers": [ - "wodann" - ], - "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA" - }, - "vector": [ - 0, - 0, - 0, - 6, 0, 0, 0, @@ -397765,6 +398126,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -397785,6 +398147,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -397835,6 +398198,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -397927,6 +398291,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -397944,7 +398309,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -397952,6 +398316,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -398120,6 +398485,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -398320,10 +398686,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, 2, 0, 0, @@ -398336,9 +398698,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr", + "sourceId": "G7AHS9", + "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR", + "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EVM", + "Hardhat", + "Optimism" + ], + "tags": [ + "Layer 2s", + "Tooling", + "DevEx", + "optimism", + "DevEx", + "Layer 2s", + "Tooling" + ], + "language": "en", + "speakers": [ + "wodann" + ], + "eventId": "devcon-7", + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -398360,15 +398763,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -398550,7 +398944,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -398736,6 +399129,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -398856,11 +399250,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -398873,49 +399265,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-i-audit", - "sourceId": "3NRXP9", - "title": "How I Audit", - "description": "Dom, a former lead auditor at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review", - "track": "Security", - "type": "Workshop", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Solidity", - "Frameworks", - "Program analysis", - "Static Analysis" - ], - "tags": [ - "Tooling", - "Security", - "Auditing", - "analysis", - "static", - "Auditing", - "Security", - "Tooling" - ], - "language": "en", - "speakers": [ - "dominik-teiml" - ], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731652200000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ" - }, - "vector": [ - 6, 0, 0, 0, @@ -399153,6 +399502,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399161,6 +399511,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399196,6 +399547,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399305,7 +399657,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -399386,6 +399737,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -399654,11 +400006,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -399675,7 +400025,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -399694,9 +400043,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -399709,6 +400060,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-i-audit", + "sourceId": "3NRXP9", + "title": "How I Audit", + "description": "Dom, a former lead auditor at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review", + "track": "Security", + "type": "Workshop", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Solidity", + "Frameworks", + "Program analysis", + "Static Analysis" + ], + "tags": [ + "Tooling", + "Security", + "Auditing", + "analysis", + "static", + "Auditing", + "Security", + "Tooling" + ], + "language": "en", + "speakers": [ + "dominik-teiml" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731652200000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ" + }, + "vector": [ + 6, 0, 0, 0, @@ -399806,7 +400200,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -400021,7 +400414,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -400102,6 +400494,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -400219,8 +400612,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -400233,48 +400624,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-long-non-finality-could-kill-ethereum", - "sourceId": "U9E7PD", - "title": "How long non-finality could kill Ethereum", - "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "-" - ], - "tags": [ - "Consensus", - "Decentralization", - "Security", - "Consensus", - "Decentralization", - "Security" - ], - "language": "en", - "speakers": [ - "dapplion" - ], - "eventId": "devcon-7", - "slot_start": 1731568200000, - "slot_end": 1731570000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -400492,9 +400845,11 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, 0, 0, 0, @@ -400511,6 +400866,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -400641,6 +400997,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -400661,7 +401018,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -400856,6 +401212,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -401009,12 +401366,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -401055,6 +401410,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -401067,10 +401424,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-long-non-finality-could-kill-ethereum", + "sourceId": "U9E7PD", + "title": "How long non-finality could kill Ethereum", + "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "-" + ], + "tags": [ + "Consensus", + "Decentralization", + "Security", + "Consensus", + "Decentralization", + "Security" + ], + "language": "en", + "speakers": [ + "dapplion" + ], + "eventId": "devcon-7", + "slot_start": 1731568200000, + "slot_end": 1731570000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -401111,7 +401506,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -401460,6 +401854,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -401571,11 +401968,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -401588,52 +401983,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality", - "sourceId": "89M7ME", - "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality", - "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "model checking", - "TLA+", - "Apalache" - ], - "tags": [ - "Consensus", - "Protocol Design", - "Formal Verification", - "apalache", - "Consensus", - "Formal Verification", - "Protocol Design" - ], - "language": "en", - "speakers": [ - "igor-konnov", - "thanh-hai-tran" - ], - "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731642000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -401791,7 +402144,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -401852,10 +402204,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -401952,6 +402306,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -401987,7 +402343,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -402373,7 +402728,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -402412,6 +402766,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 2, @@ -402427,6 +402783,60 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality", + "sourceId": "89M7ME", + "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality", + "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "model checking", + "TLA+", + "Apalache" + ], + "tags": [ + "Consensus", + "Protocol Design", + "Formal Verification", + "apalache", + "Consensus", + "Formal Verification", + "Protocol Design" + ], + "language": "en", + "speakers": [ + "igor-konnov", + "thanh-hai-tran" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731642000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -402567,7 +402977,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -402578,6 +402987,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -402736,7 +403146,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -402775,6 +403184,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -402930,12 +403340,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -402947,49 +403355,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-much-security-does-your-restaking-protocol-really-need", - "sourceId": "QDDV9C", - "title": "How much security does your restaking protocol really need?", - "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Matching Markets", - "Proof of Stake" - ], - "tags": [ - "Staking", - "Censorship Resistance", - "Economics", - "Restaking", - "proof-of", - "Censorship Resistance", - "Economics", - "Restaking" - ], - "language": "en", - "speakers": [ - "tarun-chitra" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -403205,6 +403572,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -403244,6 +403613,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -403379,7 +403749,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -403397,6 +403766,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -403564,6 +403935,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -403757,6 +404129,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -403773,6 +404146,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-much-security-does-your-restaking-protocol-really-need", + "sourceId": "QDDV9C", + "title": "How much security does your restaking protocol really need?", + "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Matching Markets", + "Proof of Stake" + ], + "tags": [ + "Staking", + "Censorship Resistance", + "Economics", + "Restaking", + "proof-of", + "Censorship Resistance", + "Economics", + "Restaking" + ], + "language": "en", + "speakers": [ + "tarun-chitra" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4" + }, + "vector": [ + 0, + 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -403855,7 +404275,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -403874,7 +404293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -404095,8 +404513,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -404164,6 +404580,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -404291,9 +404708,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -404305,46 +404720,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-audit-smart-contract-languages-brief-intro", - "sourceId": "HMYRTU", - "title": "How to Audit Smart Contract Languages: Brief Intro", - "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Language", - "Security" - ], - "tags": [ - "Languages", - "Security", - "Auditing", - "language", - "Auditing", - "Languages", - "Security" - ], - "language": "en", - "speakers": [ - "nicolas-garcia" - ], - "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731656400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY" - }, - "vector": [ - 6, 0, 0, 0, @@ -404589,6 +404964,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -404682,6 +405058,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -404700,6 +405077,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -404737,7 +405115,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -404921,6 +405298,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -405083,7 +405462,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -405116,7 +405494,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -405128,6 +405508,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-audit-smart-contract-languages-brief-intro", + "sourceId": "HMYRTU", + "title": "How to Audit Smart Contract Languages: Brief Intro", + "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Language", + "Security" + ], + "tags": [ + "Languages", + "Security", + "Auditing", + "language", + "Auditing", + "Languages", + "Security" + ], + "language": "en", + "speakers": [ + "nicolas-garcia" + ], + "eventId": "devcon-7", + "slot_start": 1731655800000, + "slot_end": 1731656400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY" + }, + "vector": [ + 6, 0, 0, 0, @@ -405180,7 +405600,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -405235,7 +405654,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -405454,7 +405872,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -405525,6 +405942,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -405645,12 +406063,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -405662,47 +406078,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-coordinate-an-epistemic-revolution", - "sourceId": "DNJMER", - "title": "How to coordinate an epistemic revolution", - "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Semantic Governance", - "Identity", - "Citizens Assembly" - ], - "tags": [ - "Consensus", - "Quadratic Voting", - "Collective Intelligence", - "citizens", - "assembly", - "Collective Intelligence", - "Consensus", - "Quadratic Voting" - ], - "language": "en", - "speakers": [ - "nick-almond" - ], - "eventId": "devcon-7", - "slot_start": 1731643800000, - "slot_end": 1731645600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4" - }, - "vector": [ 0, 0, 0, @@ -405714,7 +406089,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -405916,6 +406290,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -406012,6 +406387,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -406066,6 +406442,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -406097,7 +406474,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -406285,6 +406661,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -406447,7 +406824,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -406481,6 +406857,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -406492,6 +406869,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-coordinate-an-epistemic-revolution", + "sourceId": "DNJMER", + "title": "How to coordinate an epistemic revolution", + "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Semantic Governance", + "Identity", + "Citizens Assembly" + ], + "tags": [ + "Consensus", + "Quadratic Voting", + "Collective Intelligence", + "citizens", + "assembly", + "Collective Intelligence", + "Consensus", + "Quadratic Voting" + ], + "language": "en", + "speakers": [ + "nick-almond" + ], + "eventId": "devcon-7", + "slot_start": 1731643800000, + "slot_end": 1731645600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4" + }, + "vector": [ 0, 0, 0, @@ -406503,6 +406921,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -406653,25 +407072,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, @@ -406814,8 +407214,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -406908,6 +407306,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -407006,10 +407405,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -407021,52 +407418,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-destroy-a-network-offboarding-the-mainstream", - "sourceId": "XNCFRL", - "title": "How To Destroy A Network: Offboarding The Mainstream", - "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Values" - ], - "tags": [ - "Network State", - "Privacy", - "Anonymity", - "Digital Sovereignty", - "value", - "Anonymity", - "Digital Sovereignty", - "Network State", - "Privacy" - ], - "language": "en", - "speakers": [ - "laurence-day" - ], - "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731486000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -407302,6 +407658,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -407330,6 +407687,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -407456,7 +407814,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -407507,6 +407864,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -407667,6 +408025,19 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -407826,7 +408197,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -407862,11 +408232,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-destroy-a-network-offboarding-the-mainstream", + "sourceId": "XNCFRL", + "title": "How To Destroy A Network: Offboarding The Mainstream", + "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Values" + ], + "tags": [ + "Network State", + "Privacy", + "Anonymity", + "Digital Sovereignty", + "value", + "Anonymity", + "Digital Sovereignty", + "Network State", + "Privacy" + ], + "language": "en", + "speakers": [ + "laurence-day" + ], + "eventId": "devcon-7", + "slot_start": 1731484200000, + "slot_end": 1731486000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -407917,7 +408328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -408174,7 +408584,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -408260,6 +408669,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -408362,7 +408772,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -408371,7 +408780,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -408379,49 +408787,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-do-something-to-some-state-in-some-contract", - "sourceId": "HECBJV", - "title": "How to do something to some state in some contract", - "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.", - "track": "Applied Cryptography", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ZKDSL", - "DevOps", - "Mobile Proving" - ], - "tags": [ - "DevEx", - "Privacy", - "Decentralization", - "Cryptography", - "Mobile", - "proving", - "Cryptography", - "Decentralization", - "DevEx", - "Privacy" - ], - "language": "en", - "speakers": [ - "jose-pedro-sousa-or-zpedro" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731644100000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc" - }, - "vector": [ 0, 0, 0, @@ -408432,7 +408797,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -408677,6 +409041,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -408697,8 +409062,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -408765,6 +409132,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -408818,7 +409186,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -409022,6 +409389,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -409174,7 +409542,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -409184,14 +409551,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -409212,10 +409577,66 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 0, 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "how-to-do-something-to-some-state-in-some-contract", + "sourceId": "HECBJV", + "title": "How to do something to some state in some contract", + "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.", + "track": "Applied Cryptography", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZKDSL", + "DevOps", + "Mobile Proving" + ], + "tags": [ + "DevEx", + "Privacy", + "Decentralization", + "Cryptography", + "Mobile", + "proving", + "Cryptography", + "Decentralization", + "DevEx", + "Privacy" + ], + "language": "en", + "speakers": [ + "jose-pedro-sousa-or-zpedro" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731644100000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc" + }, + "vector": [ 0, 0, 0, @@ -409226,6 +409647,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -409263,7 +409685,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -409276,9 +409697,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -409616,6 +410035,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -409723,11 +410143,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -409740,40 +410158,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-hallucinate-a-server", - "sourceId": "QNFTYG", - "title": "How To Hallucinate A Server", - "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "MPFHE", - "Hallucinated Server" - ], - "tags": [ - "Homomorphic Encryption", - "MPC" - ], - "language": "en", - "speakers": [ - "gubsheep" - ], - "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk" - }, - "vector": [ 0, 0, 0, @@ -409784,7 +410168,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -409961,7 +410344,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -410011,6 +410393,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -410020,12 +410403,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -410097,6 +410482,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -410109,7 +410495,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -410554,9 +410942,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -410569,6 +410959,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-hallucinate-a-server", + "sourceId": "QNFTYG", + "title": "How To Hallucinate A Server", + "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "MPFHE", + "Hallucinated Server" + ], + "tags": [ + "Homomorphic Encryption", + "MPC" + ], + "language": "en", + "speakers": [ + "gubsheep" + ], + "eventId": "devcon-7", + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk" + }, + "vector": [ 0, 0, 0, @@ -410579,6 +411003,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -410602,8 +411027,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -410758,6 +411181,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -411075,11 +411499,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -411089,57 +411511,12 @@ 0, 0, 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography", - "sourceId": "SDPVVF", - "title": "How to onboard 22 million users overnight using non-conventional cryptography", - "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ERC-4337", - "RSA", - "PKI" - ], - "tags": [ - "Identity", - "Cryptography", - "Account Abstraction", - "pki", - "Account Abstraction", - "Cryptography", - "Identity" - ], - "language": "en", - "speakers": [ - "ernesto-garcia" - ], - "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731480000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -411243,7 +411620,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -411449,6 +411825,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -411884,7 +412262,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -411920,12 +412297,12 @@ 0, 0, 0, - 2, 0, 2, 0, 0, 0, + 2, 0, 0, 0, @@ -411938,12 +412315,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography", + "sourceId": "SDPVVF", + "title": "How to onboard 22 million users overnight using non-conventional cryptography", + "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ERC-4337", + "RSA", + "PKI" + ], + "tags": [ + "Identity", + "Cryptography", + "Account Abstraction", + "pki", + "Account Abstraction", + "Cryptography", + "Identity" + ], + "language": "en", + "speakers": [ + "ernesto-garcia" + ], + "eventId": "devcon-7", + "slot_start": 1731479400000, + "slot_end": 1731480000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -412049,6 +412467,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -412246,22 +412665,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -412433,7 +412836,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -412442,7 +412844,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -412450,52 +412851,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data", - "sourceId": "UASADN", - "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data", - "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Gas limit", - "State growth", - "History growth", - "Bandwidth" - ], - "tags": [ - "Layer 1", - "Gas", - "Scalability", - "bandwidth", - "Gas", - "Layer 1", - "Scalability" - ], - "language": "en", - "speakers": [ - "storm-slivkoff" - ], - "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731570000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -412752,6 +413111,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -412787,7 +413147,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -412888,7 +413250,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -413112,6 +413473,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -413245,7 +413607,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -413299,6 +413660,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -413307,6 +413669,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -413314,10 +413677,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data", + "sourceId": "UASADN", + "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data", + "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Gas limit", + "State growth", + "History growth", + "Bandwidth" + ], + "tags": [ + "Layer 1", + "Gas", + "Scalability", + "bandwidth", + "Gas", + "Layer 1", + "Scalability" + ], + "language": "en", + "speakers": [ + "storm-slivkoff" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731570000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -413370,7 +413775,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -413460,7 +413864,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -413606,7 +414009,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -413715,6 +414117,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -413792,12 +414195,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -413809,47 +414210,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes", - "sourceId": "TJ833L", - "title": "How to steal $1.1M from lending market in 15 minutes", - "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "defi", - "lending protocols", - "exploit" - ], - "tags": [ - "Security", - "Auditing", - "Bug", - "exploits", - "Auditing", - "Bug", - "Security" - ], - "language": "en", - "speakers": [ - "bartosz-barwikowski" - ], - "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731658200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM" - }, - "vector": [ - 6, 0, 0, 0, @@ -414116,6 +414476,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -414240,6 +414601,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -414247,7 +414609,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -414330,6 +414691,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -414475,6 +414837,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -414588,7 +414951,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -414661,10 +415023,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -414676,6 +415040,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes", + "sourceId": "TJ833L", + "title": "How to steal $1.1M from lending market in 15 minutes", + "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "defi", + "lending protocols", + "exploit" + ], + "tags": [ + "Security", + "Auditing", + "Bug", + "exploits", + "Auditing", + "Bug", + "Security" + ], + "language": "en", + "speakers": [ + "bartosz-barwikowski" + ], + "eventId": "devcon-7", + "slot_start": 1731657600000, + "slot_end": 1731658200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM" + }, + "vector": [ + 6, 0, 0, 0, @@ -414740,7 +415145,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -414863,7 +415267,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -414965,7 +415368,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -415078,6 +415480,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -415150,11 +415554,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -415167,59 +415569,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy", - "sourceId": "GFAA97", - "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.", - "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Business", - "featured": false, - "doNotRecord": false, - "tags": [ - "RWA", - "Economics", - "web3", - "Economics", - "RWA" - ], - "keywords": [ - "Web3" - ], - "duration": 1461, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "yuEFLaSk7us", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU", - "resources_slides": null, - "speakers": [ - "justin-banon", - "jason-potts" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -415468,6 +415823,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -415612,14 +415969,13 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -415742,6 +416098,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -415843,6 +416200,31 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -415987,7 +416369,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -416004,9 +416385,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -416019,12 +416402,59 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy", + "sourceId": "GFAA97", + "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.", + "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Business", + "featured": false, + "doNotRecord": false, + "tags": [ + "RWA", + "Economics", + "web3", + "Economics", + "RWA" + ], + "keywords": [ + "Web3" + ], + "duration": 1461, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "yuEFLaSk7us", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU", + "resources_slides": null, + "speakers": [ + "justin-banon", + "jason-potts" + ] + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -416106,7 +416536,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -416330,7 +416759,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -416421,6 +416849,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -416514,14 +416944,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -416531,60 +416959,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef", - "sourceId": "7SXGVX", - "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)", - "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.", - "track": "Real World Ethereum", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "real", - "world", - "usecases" - ], - "tags": [ - "Free Speech", - "Not financial", - "Public good", - "Quadratic Voting", - "Use Cases" - ], - "language": "en", - "speakers": [ - "team-next-billion-ef", - "david-uzochukwu", - "eddie-kago", - "guo-liu", - "mercedes-rodriguez-simon", - "valeriia-panina", - "karam-alhamad", - "tomislav-mamic", - "rebecca-mqamelo", - "lefteris-arapakis" - ], - "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731497400000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -416657,7 +417037,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -416847,6 +417226,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -416946,7 +417326,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -416966,6 +417345,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -416979,14 +417365,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -417191,6 +417569,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -417344,35 +417730,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, @@ -417403,6 +417760,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -417412,12 +417770,60 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef", + "sourceId": "7SXGVX", + "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)", + "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.", + "track": "Real World Ethereum", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "real", + "world", + "usecases" + ], + "tags": [ + "Free Speech", + "Not financial", + "Public good", + "Quadratic Voting", + "Use Cases" + ], + "language": "en", + "speakers": [ + "team-next-billion-ef", + "david-uzochukwu", + "eddie-kago", + "guo-liu", + "mercedes-rodriguez-simon", + "valeriia-panina", + "karam-alhamad", + "tomislav-mamic", + "rebecca-mqamelo", + "lefteris-arapakis" + ], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731497400000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -417426,10 +417832,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -417495,6 +417897,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -417528,7 +417931,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -417556,7 +417958,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -417786,6 +418187,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -417818,6 +418220,14 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -417881,14 +418291,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -417896,56 +418304,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations", - "sourceId": "UQ8MWW", - "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations", - "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!", - "track": "Core Protocol", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Python", - "Pytest", - "Specs" - ], - "tags": [ - "Core Protocol", - "Security", - "Testing", - "python", - "pytest", - "specs", - "Core Protocol", - "Security", - "Testing" - ], - "language": "en", - "speakers": [ - "mario-vega", - "danceratopz", - "dimitry-kh", - "spencer-taylor-brown" - ], - "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731479400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -418225,6 +418587,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418276,6 +418639,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418305,6 +418669,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418350,10 +418715,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -418410,6 +418771,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418437,6 +418799,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -418680,7 +419043,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -418699,7 +419061,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -418763,12 +419124,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -418776,10 +419139,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations", + "sourceId": "UQ8MWW", + "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations", + "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Python", + "Pytest", + "Specs" + ], + "tags": [ + "Core Protocol", + "Security", + "Testing", + "python", + "pytest", + "specs", + "Core Protocol", + "Security", + "Testing" + ], + "language": "en", + "speakers": [ + "mario-vega", + "danceratopz", + "dimitry-kh", + "spencer-taylor-brown" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731479400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -418923,7 +419332,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -419059,9 +419467,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -419190,6 +419595,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -419242,11 +419651,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -419259,50 +419666,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know", - "sourceId": "V8FHZL", - "title": "I read every single 1990s Cypherpunk email. Here's what you should know.", - "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Cypherpunk" - ], - "tags": [ - "Permissionless", - "Free Speech", - "Censorship Resistance", - "cypherpunk", - "Censorship Resistance", - "Free Speech", - "Permissionless" - ], - "language": "en", - "speakers": [ - "porter-adams" - ], - "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -419559,6 +419927,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -419577,6 +419946,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -419710,7 +420080,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -419801,6 +420170,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -419936,6 +420306,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -420063,7 +420436,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -420117,9 +420489,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -420132,11 +420506,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know", + "sourceId": "V8FHZL", + "title": "I read every single 1990s Cypherpunk email. Here's what you should know.", + "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Cypherpunk" + ], + "tags": [ + "Permissionless", + "Free Speech", + "Censorship Resistance", + "cypherpunk", + "Censorship Resistance", + "Free Speech", + "Permissionless" + ], + "language": "en", + "speakers": [ + "porter-adams" + ], + "eventId": "devcon-7", + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -420184,7 +420597,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -420228,7 +420640,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -420418,7 +420829,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -420549,6 +420959,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -420600,14 +421011,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -420615,41 +421024,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "impossibility-within-dynamically-available-protocols", - "sourceId": "SUNDNH", - "title": "Impossibility within Dynamically Available Protocols", - "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Academic", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Dynamic", - "Availability" - ], - "tags": [ - "Consensus Mechanisms", - "Finality", - "Single-slot Finality" - ], - "language": "en", - "speakers": [ - "yash-saraswat" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489300000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc" - }, - "vector": [ 0, 0, 0, @@ -420665,7 +421039,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -420941,6 +421314,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -421061,10 +421435,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 6, 0, 0, 0, @@ -421105,6 +421479,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -421294,6 +421669,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -421475,12 +421851,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -421488,6 +421866,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "impossibility-within-dynamically-available-protocols", + "sourceId": "SUNDNH", + "title": "Impossibility within Dynamically Available Protocols", + "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Academic", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Dynamic", + "Availability" + ], + "tags": [ + "Consensus Mechanisms", + "Finality", + "Single-slot Finality" + ], + "language": "en", + "speakers": [ + "yash-saraswat" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731489300000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc" + }, + "vector": [ 0, 0, 0, @@ -421503,6 +421916,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -421585,7 +421999,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421772,8 +422185,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -421906,6 +422317,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -421954,7 +422366,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -421964,54 +422375,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "improving-the-user-experience-by-user-research", - "sourceId": "ZVUFEY", - "title": "Improving the User Experience by User Research.", - "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.", - "track": "Usability", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Customer Journey Map", - "In-depth interviews", - "Blockchain Mass Adoption." - ], - "tags": [ - "User Experience", - "Interface", - "Accessibility", - "User Research", - "adoption", - "blockchain", - "mass", - "Accessibility", - "Interface", - "User Experience", - "User Research" - ], - "language": "en", - "speakers": [ - "andrii-bondar" - ], - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731394800000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0" - }, - "vector": [ 0, 0, 0, @@ -422020,7 +422386,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -422427,7 +422792,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -422476,6 +422840,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -422662,6 +423027,14 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -422767,7 +423140,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -422811,7 +423183,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -422848,9 +423219,54 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "improving-the-user-experience-by-user-research", + "sourceId": "ZVUFEY", + "title": "Improving the User Experience by User Research.", + "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.", + "track": "Usability", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Customer Journey Map", + "In-depth interviews", + "Blockchain Mass Adoption." + ], + "tags": [ + "User Experience", + "Interface", + "Accessibility", + "User Research", + "adoption", + "blockchain", + "mass", + "Accessibility", + "Interface", + "User Experience", + "User Research" + ], + "language": "en", + "speakers": [ + "andrii-bondar" + ], + "eventId": "devcon-7", + "slot_start": 1731389400000, + "slot_end": 1731394800000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0" + }, + "vector": [ 0, 0, 0, @@ -422859,6 +423275,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -422893,7 +423313,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -422909,8 +423328,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -422952,7 +423369,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -423268,6 +423684,22 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -423315,13 +423747,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -423330,53 +423760,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "incentivizing-defensive-technologies-for-ethereum", - "sourceId": "HTNYKL", - "title": "Incentivizing Defensive Technologies for Ethereum", - "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "d/acc", - "defensive technologies" - ], - "tags": [ - "Regenative Ethereum", - "Ethereum for Good", - "e/acc", - "technology", - "defense", - "e/acc", - "Ethereum for Good", - "Regenative Ethereum" - ], - "language": "en", - "speakers": [ - "han-tuzun" - ], - "eventId": "devcon-7", - "slot_start": 1731658200000, - "slot_end": 1731658800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -423637,6 +424026,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -423680,6 +424070,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -423706,6 +424097,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -423760,6 +424152,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -423775,6 +424168,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -423786,7 +424181,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -423817,6 +424211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -424179,11 +424574,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -424192,12 +424589,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "incentivizing-defensive-technologies-for-ethereum", + "sourceId": "HTNYKL", + "title": "Incentivizing Defensive Technologies for Ethereum", + "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "d/acc", + "defensive technologies" + ], + "tags": [ + "Regenative Ethereum", + "Ethereum for Good", + "e/acc", + "technology", + "defense", + "e/acc", + "Ethereum for Good", + "Regenative Ethereum" + ], + "language": "en", + "speakers": [ + "han-tuzun" + ], + "eventId": "devcon-7", + "slot_start": 1731658200000, + "slot_end": 1731658800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -424235,7 +424673,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -424265,7 +424702,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -424494,9 +424930,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -424614,6 +425047,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -424673,9 +425107,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -424688,32 +425120,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "inch", - "sourceId": "AWQHPU", - "title": "INCH", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731583800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw" - }, - "vector": [ 0, 0, 0, @@ -424723,7 +425129,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -425093,6 +425498,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -425122,6 +425528,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -425350,6 +425757,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -425526,7 +425936,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -425539,6 +425951,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "inch", + "sourceId": "AWQHPU", + "title": "INCH", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731583800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw" + }, + "vector": [ 0, 0, 0, @@ -425548,6 +425986,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -426016,10 +426459,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -426032,47 +426473,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "inclusion-list-inevitable-tradeoffs", - "sourceId": "XEE9EG", - "title": "Inclusion List Inevitable Tradeoffs", - "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "inclusion", - "list" - ], - "tags": [ - "Decentralization Improvements", - "Censorship Resistance", - "inclusivity", - "lists", - "Censorship Resistance", - "Decentralization Improvements" - ], - "language": "en", - "speakers": [ - "terence" - ], - "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731490200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -426410,7 +426812,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -426815,7 +427216,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -426883,6 +427283,10 @@ 0, 0, 0, + 2, + 0, + 0, + 2, 0, 0, 0, @@ -426894,8 +427298,48 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "inclusion-list-inevitable-tradeoffs", + "sourceId": "XEE9EG", + "title": "Inclusion List Inevitable Tradeoffs", + "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "inclusion", + "list" + ], + "tags": [ + "Decentralization Improvements", + "Censorship Resistance", + "inclusivity", + "lists", + "Censorship Resistance", + "Decentralization Improvements" + ], + "language": "en", + "speakers": [ + "terence" + ], + "eventId": "devcon-7", + "slot_start": 1731489600000, + "slot_end": 1731490200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -426957,7 +427401,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -427197,8 +427640,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -427238,6 +427679,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -427373,9 +427815,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -427388,50 +427828,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours", - "sourceId": "QEDEUG", - "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours", - "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.", - "track": "Developer Experience", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Data", - "Processing" - ], - "tags": [ - "Architecture", - "Scalability", - "Event monitoring", - "data", - "processor", - "Architecture", - "Event monitoring", - "Scalability" - ], - "language": "en", - "speakers": [ - "panjamapong-panj-sermsawatsri" - ], - "eventId": "devcon-7", - "slot_start": 1731492600000, - "slot_end": 1731493200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -427687,6 +428086,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -427828,6 +428228,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -427845,7 +428246,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -428068,6 +428468,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -428229,7 +428631,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428243,7 +428644,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -428256,9 +428659,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours", + "sourceId": "QEDEUG", + "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours", + "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Data", + "Processing" + ], + "tags": [ + "Architecture", + "Scalability", + "Event monitoring", + "data", + "processor", + "Architecture", + "Event monitoring", + "Scalability" + ], + "language": "en", + "speakers": [ + "panjamapong-panj-sermsawatsri" + ], + "eventId": "devcon-7", + "slot_start": 1731492600000, + "slot_end": 1731493200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -428307,7 +428751,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428420,7 +428863,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428478,7 +428920,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428557,7 +428998,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -428678,6 +429118,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -428729,67 +429170,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "indexing-ethereum-when-and-how-to-build-an-indexer", - "sourceId": "BGGFDD", - "title": "Indexing Ethereum: When and How to Build an Indexer", - "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "database", - "indexing", - "infrastructure" - ], - "tags": [ - "Architecture", - "Developer Infrastructure", - "Best Practices", - "infrastructure", - "Architecture", - "Best Practices", - "Developer Infrastructure" - ], - "language": "en", - "speakers": [ - "ryan-smith" - ], - "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731483000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E" - }, - "vector": [ - 0, - 0, - 0, - 6, 0, 0, 0, @@ -429121,6 +429504,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429198,13 +429582,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -429311,6 +429695,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429368,6 +429753,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429446,6 +429832,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -429556,7 +429943,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -429579,7 +429965,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -429587,7 +429972,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -429620,9 +430004,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -429635,9 +430021,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "indexing-ethereum-when-and-how-to-build-an-indexer", + "sourceId": "BGGFDD", + "title": "Indexing Ethereum: When and How to Build an Indexer", + "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "database", + "indexing", + "infrastructure" + ], + "tags": [ + "Architecture", + "Developer Infrastructure", + "Best Practices", + "infrastructure", + "Architecture", + "Best Practices", + "Developer Infrastructure" + ], + "language": "en", + "speakers": [ + "ryan-smith" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731483000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -429713,7 +430140,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -430055,6 +430481,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -430087,11 +430514,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -430104,42 +430529,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "indistinguishability-obfuscation-io", - "sourceId": "KDUKFD", - "title": "Indistinguishability Obfuscation (iO)", - "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Programmable Cryptography", - "iO" - ], - "tags": [ - "Cryptography" - ], - "language": "en", - "speakers": [ - "barry", - "tianyao-gu", - "brian-lawrence", - "janmajaya-mall" - ], - "eventId": "devcon-7", - "slot_start": 1731654900000, - "slot_end": 1731660300000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk" - }, - "vector": [ 0, 0, 0, @@ -430154,7 +430543,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -430332,7 +430720,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -430448,6 +430835,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -430470,6 +430858,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -430477,6 +430866,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -430520,7 +430910,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -430559,8 +430948,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -430605,6 +430992,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -430892,7 +431280,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -430979,9 +431366,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -430994,6 +431383,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "indistinguishability-obfuscation-io", + "sourceId": "KDUKFD", + "title": "Indistinguishability Obfuscation (iO)", + "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Programmable Cryptography", + "iO" + ], + "tags": [ + "Cryptography" + ], + "language": "en", + "speakers": [ + "barry", + "tianyao-gu", + "brian-lawrence", + "janmajaya-mall" + ], + "eventId": "devcon-7", + "slot_start": 1731654900000, + "slot_end": 1731660300000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk" + }, + "vector": [ 0, 0, 0, @@ -431008,6 +431433,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -431186,6 +431612,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -431374,6 +431801,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -431412,6 +431840,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -431441,7 +431871,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -431455,54 +431884,12 @@ 0, 0, 0, - 2, 0, 0, - 0 - ] - }, - { - "session": { - "id": "insights-from-block-propagation-in-the-ethereum-p2p-network", - "sourceId": "T8GXPY", - "title": "Insights from block propagation in the Ethereum P2P network", - "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Block Propagation", - "Networking Protocols" - ], - "tags": [ - "Core Protocol", - "Architecture", - "Scalability", - "network", - "protocol", - "Architecture", - "Core Protocol", - "Scalability" - ], - "language": "en", - "speakers": [ - "mikel-cortes-cortze" - ], - "eventId": "devcon-7", - "slot_start": 1731570600000, - "slot_end": 1731571200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -431788,6 +432175,21 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -431919,7 +432321,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -432256,7 +432657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -432299,7 +432699,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -432339,6 +432738,58 @@ 0, 0, 0, + 2, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "insights-from-block-propagation-in-the-ethereum-p2p-network", + "sourceId": "T8GXPY", + "title": "Insights from block propagation in the Ethereum P2P network", + "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Block Propagation", + "Networking Protocols" + ], + "tags": [ + "Core Protocol", + "Architecture", + "Scalability", + "network", + "protocol", + "Architecture", + "Core Protocol", + "Scalability" + ], + "language": "en", + "speakers": [ + "mikel-cortes-cortze" + ], + "eventId": "devcon-7", + "slot_start": 1731570600000, + "slot_end": 1731571200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -432377,7 +432828,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -432628,7 +433078,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -432755,6 +433204,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -432799,12 +433249,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -432816,46 +433264,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "interoperability-between-l2s-latest-developments-framework-and-challenges", - "sourceId": "3ZH9ST", - "title": "Interoperability between L2s: Latest developments, Framework and Challenges", - "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Composability", - "Interoperability" - ], - "tags": [ - "Fragmentation", - "Cross-L2", - "Developer Infrastructure", - "interoperability", - "Cross-L2", - "Developer Infrastructure", - "Fragmentation" - ], - "language": "en", - "speakers": [ - "marshall-vyletel-jr", - "wei-dai" - ], - "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek" - }, - "vector": [ 0, 0, 0, @@ -432863,7 +433271,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -433136,6 +433543,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433178,6 +433586,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433203,6 +433612,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433254,6 +433664,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433278,8 +433689,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -433506,6 +433915,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -433638,7 +434048,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -433649,7 +434058,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -433678,10 +434086,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -433693,6 +434103,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "interoperability-between-l2s-latest-developments-framework-and-challenges", + "sourceId": "3ZH9ST", + "title": "Interoperability between L2s: Latest developments, Framework and Challenges", + "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Composability", + "Interoperability" + ], + "tags": [ + "Fragmentation", + "Cross-L2", + "Developer Infrastructure", + "interoperability", + "Cross-L2", + "Developer Infrastructure", + "Fragmentation" + ], + "language": "en", + "speakers": [ + "marshall-vyletel-jr", + "wei-dai" + ], + "eventId": "devcon-7", + "slot_start": 1731579600000, + "slot_end": 1731580200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek" + }, + "vector": [ 0, 0, 0, @@ -433700,6 +434150,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -433797,7 +434248,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -433987,7 +434437,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -434118,6 +434567,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -434157,11 +434608,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -434174,55 +434623,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "interpreting-solidity", - "sourceId": "GQAEZX", - "title": "Interpreting Solidity", - "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", - "featured": false, - "doNotRecord": true, - "keywords": [ - "NA" - ], - "tags": [ - "Developer Infrastructure", - "Tooling", - "Languages", - "Developer Infrastructure", - "Languages", - "Tooling" - ], - "language": "en", - "speakers": [ - "daniel-perez" - ], - "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731580200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM" - }, - "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -434529,6 +434929,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434539,6 +434940,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434635,7 +435037,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -434687,6 +435088,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434876,6 +435278,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -434971,7 +435374,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -435004,7 +435406,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -435051,6 +435452,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -435063,9 +435465,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "interpreting-solidity", + "sourceId": "GQAEZX", + "title": "Interpreting Solidity", + "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", + "featured": false, + "doNotRecord": true, + "keywords": [ + "NA" + ], + "tags": [ + "Developer Infrastructure", + "Tooling", + "Languages", + "Developer Infrastructure", + "Languages", + "Tooling" + ], + "language": "en", + "speakers": [ + "daniel-perez" + ], + "eventId": "devcon-7", + "slot_start": 1731578400000, + "slot_end": 1731580200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -435488,6 +435928,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -435510,65 +435951,6 @@ 0, 0, 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "introducing-provable-object-data", - "sourceId": "YP9HRR", - "title": "Introducing Provable Object Data", - "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Zupass", - "developers", - "POD" - ], - "tags": [ - "Libraries", - "Zero-Knowledge", - "Use cases of cryptography", - "pod", - "Libraries", - "Use cases of cryptography", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "andrew-twyman" - ], - "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo" - }, - "vector": [ 0, 0, 0, @@ -435579,7 +435961,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -435592,7 +435973,6 @@ 0, 0, 0, - 4, 0, 0, 0, @@ -435886,6 +436266,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -435918,6 +436299,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -435960,6 +436342,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -436319,8 +436702,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -436336,7 +436717,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -436427,6 +436807,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -436438,10 +436819,51 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "introducing-provable-object-data", + "sourceId": "YP9HRR", + "title": "Introducing Provable Object Data", + "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Zupass", + "developers", + "POD" + ], + "tags": [ + "Libraries", + "Zero-Knowledge", + "Use cases of cryptography", + "pod", + "Libraries", + "Use cases of cryptography", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "andrew-twyman" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731571200000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo" + }, + "vector": [ 0, 0, 0, @@ -436452,6 +436874,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -436465,6 +436888,7 @@ 0, 0, 0, + 4, 0, 0, 0, @@ -436701,7 +437125,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -436872,11 +437295,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -436887,45 +437308,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "introduction-to-hash-based-proof-systems", - "sourceId": "EUAERD", - "title": "Introduction to hash-based proof systems", - "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Binius", - "Reed-Solomon" - ], - "tags": [ - "Scalability", - "ZKP", - "STARK", - "reed-solomon", - "Scalability", - "STARK", - "ZKP" - ], - "language": "en", - "speakers": [ - "diego-kingston" - ], - "eventId": "devcon-7", - "slot_start": 1731392400000, - "slot_end": 1731393000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU" - }, - "vector": [ 0, 0, 0, @@ -436936,7 +437318,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -437237,6 +437618,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -437252,6 +437635,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -437351,7 +437735,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -437617,6 +438000,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -437740,7 +438124,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -437788,9 +438171,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -437801,17 +438186,56 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "introduction-to-hash-based-proof-systems", + "sourceId": "EUAERD", + "title": "Introduction to hash-based proof systems", + "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Binius", + "Reed-Solomon" + ], + "tags": [ + "Scalability", + "ZKP", + "STARK", + "reed-solomon", + "Scalability", + "STARK", + "ZKP" + ], + "language": "en", + "speakers": [ + "diego-kingston" + ], + "eventId": "devcon-7", + "slot_start": 1731392400000, + "slot_end": 1731393000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU" + }, + "vector": [ 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -437878,7 +438302,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -438059,7 +438482,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -438229,9 +438651,8 @@ 0, 0, 0, - 2, 0, - 2, + 6, 0, 0, 0, @@ -438244,49 +438665,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc", - "sourceId": "VYD38F", - "title": "Introduction to Multilateral Trade Credit Set-off in MPC", - "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "finance" - ], - "keywords": [ - "MPC", - "cryptography", - "finance" - ], - "duration": 680, - "language": "en", - "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb", - "sources_youtubeId": "OCEEe8azbR8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731391800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls", - "resources_slides": null, - "speakers": [ - "enrico-bottazzi" - ] - }, - "vector": [ 0, 0, 0, @@ -438297,7 +438675,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -438666,6 +439043,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -438713,7 +439091,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -438731,6 +439108,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -438803,6 +439181,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -438983,6 +439362,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -439152,7 +439532,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -439165,6 +439547,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc", + "sourceId": "VYD38F", + "title": "Introduction to Multilateral Trade Credit Set-off in MPC", + "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "finance" + ], + "keywords": [ + "MPC", + "cryptography", + "finance" + ], + "duration": 680, + "language": "en", + "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb", + "sources_youtubeId": "OCEEe8azbR8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731391200000, + "slot_end": 1731391800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls", + "resources_slides": null, + "speakers": [ + "enrico-bottazzi" + ] + }, + "vector": [ 0, 0, 0, @@ -439175,6 +439600,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -439421,7 +439847,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -439588,13 +440013,12 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, + 6, 0, 0, 0, @@ -439605,34 +440029,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "io", - "sourceId": "9BQWGB", - "title": "iO", - "description": "It will be worth it ;)", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "barry-whitehat" - ], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA" - }, - "vector": [ 0, 0, 0, @@ -439643,7 +440039,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -440060,7 +440455,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -440334,6 +440728,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -440500,9 +440895,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -440515,6 +440912,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "io", + "sourceId": "9BQWGB", + "title": "iO", + "description": "It will be worth it ;)", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "barry-whitehat" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA" + }, + "vector": [ 0, 0, 0, @@ -440525,6 +440950,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -440935,65 +441361,23 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data", - "sourceId": "E3JADX", - "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data", - "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Multi-block MEV", - "Data Analysis" - ], - "tags": [ - "Economics", - "Tokenomics", - "MEV", - "data", - "analysis", - "Economics", - "MEV", - "Tokenomics" - ], - "language": "en", - "speakers": [ - "pascal-stichler" - ], - "eventId": "devcon-7", - "slot_start": 1731639300000, - "slot_end": 1731639900000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -441032,7 +441416,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -441732,9 +442115,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -441765,7 +442146,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -441774,7 +442154,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -441867,8 +442246,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -441881,8 +442262,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data", + "sourceId": "E3JADX", + "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data", + "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Multi-block MEV", + "Data Analysis" + ], + "tags": [ + "Economics", + "Tokenomics", + "MEV", + "data", + "analysis", + "Economics", + "MEV", + "Tokenomics" + ], + "language": "en", + "speakers": [ + "pascal-stichler" + ], + "eventId": "devcon-7", + "slot_start": 1731639300000, + "slot_end": 1731639900000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -441922,6 +442344,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -442041,7 +442464,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -442292,12 +442714,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -442309,52 +442729,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "issuance-endgame-stake-targeting", - "sourceId": "39HYEG", - "title": "Issuance Endgame: Stake Targeting", - "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like. \r\n\r\nWe argue that it should include an issuance policy that targets a range of staking ratios instead. The intention is to be secure enough but avoid overpaying for security and thereby enabling said negative externalities.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "none" - ], - "tags": [ - "ACD", - "Staking", - "Economics", - "ACD", - "Economics", - "Staking" - ], - "language": "en", - "speakers": [ - "caspar-schwarz-schilling", - "ansgar-dietrichs" - ], - "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8" - }, - "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -442403,7 +442781,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -442670,7 +443047,9 @@ 0, 0, 0, + 6, 0, + 6, 0, 0, 0, @@ -442701,6 +443080,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -442709,6 +443089,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -442775,7 +443156,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -442976,6 +443356,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -443121,7 +443502,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -443215,7 +443595,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -443228,10 +443607,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -443243,10 +443624,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "issuance-endgame-stake-targeting", + "sourceId": "39HYEG", + "title": "Issuance Endgame: Stake Targeting", + "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like. \r\n\r\nWe argue that it should include an issuance policy that targets a range of staking ratios instead. The intention is to be secure enough but avoid overpaying for security and thereby enabling said negative externalities.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "none" + ], + "tags": [ + "ACD", + "Staking", + "Economics", + "ACD", + "Economics", + "Staking" + ], + "language": "en", + "speakers": [ + "caspar-schwarz-schilling", + "ansgar-dietrichs" + ], + "eventId": "devcon-7", + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -443299,6 +443719,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -443373,7 +443794,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -443648,12 +444068,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -443665,32 +444083,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "jackson-the-dev", - "sourceId": "GGHN3U", - "title": "Jackson the Dev", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731664800000, - "slot_end": 1731668400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4" - }, - "vector": [ 0, 0, 0, @@ -444048,6 +444440,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -444141,6 +444534,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -444298,6 +444692,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -444572,10 +444967,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -444587,6 +444984,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "jackson-the-dev", + "sourceId": "GGHN3U", + "title": "Jackson the Dev", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731664800000, + "slot_end": 1731668400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4" + }, + "vector": [ 0, 0, 0, @@ -444596,6 +445019,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -444993,57 +445417,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "json-rpc-enhancement-in-geth", - "sourceId": "7KZLFF", - "title": "JSON-RPC Enhancement in Geth", - "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "execution client", - "json-rpc" - ], - "tags": [ - "Architecture", - "Frameworks", - "User Experience" - ], - "language": "en", - "speakers": [ - "jsvisa" - ], - "eventId": "devcon-7", - "slot_start": 1731469500000, - "slot_end": 1731470400000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc" - }, - "vector": [ 0, 0, 0, @@ -445059,7 +445432,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -445473,7 +445845,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -445799,7 +446170,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -445845,7 +446215,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -445888,7 +446257,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -445948,8 +446316,73 @@ 0, 0, 0, + 2, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "json-rpc-enhancement-in-geth", + "sourceId": "7KZLFF", + "title": "JSON-RPC Enhancement in Geth", + "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "execution client", + "json-rpc" + ], + "tags": [ + "Architecture", + "Frameworks", + "User Experience" + ], + "language": "en", + "speakers": [ + "jsvisa" + ], + "eventId": "devcon-7", + "slot_start": 1731469500000, + "slot_end": 1731470400000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, 0, 0, 0, @@ -446345,11 +446778,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -446362,43 +446793,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-glass-houses-and-tornados", - "sourceId": "K9A8EG", - "title": "Keynote: Glass Houses and Tornados", - "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Lobby", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Legal", - "Government", - "Regulation" - ], - "tags": [ - "Governance", - "Mixers", - "Open Source Software", - "Privacy" - ], - "language": "en", - "speakers": [ - "peter-van-valkenburgh" - ], - "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731649800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c" - }, - "vector": [ 0, 0, 0, @@ -446732,6 +447126,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -446776,6 +447172,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -446818,6 +447215,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -446829,7 +447228,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -447234,9 +447632,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -447255,7 +447651,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -447277,6 +447672,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -447289,11 +447689,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-glass-houses-and-tornados", + "sourceId": "K9A8EG", + "title": "Keynote: Glass Houses and Tornados", + "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Lobby", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Legal", + "Government", + "Regulation" + ], + "tags": [ + "Governance", + "Mixers", + "Open Source Software", + "Privacy" + ], + "language": "en", + "speakers": [ + "peter-van-valkenburgh" + ], + "eventId": "devcon-7", + "slot_start": 1731648600000, + "slot_end": 1731649800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -447534,7 +447972,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -447700,7 +448137,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -447717,46 +448153,6 @@ 0, 0, 0, - 2 - ] - }, - { - "session": { - "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation", - "sourceId": "MDHXHK", - "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation", - "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Linux Foundation", - "Open Development" - ], - "tags": [ - "Open Source Software", - "FOSS", - "Best Practices", - "development", - "open", - "Best Practices", - "FOSS", - "Open Source Software" - ], - "language": "en", - "speakers": [ - "hart-montgomery" - ], - "eventId": "devcon-7", - "slot_start": 1731649800000, - "slot_end": 1731651600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8" - }, - "vector": [ 0, 0, 0, @@ -447847,7 +448243,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -448170,6 +448565,13 @@ 0, 0, 0, + 2, + 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -448184,6 +448586,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -448462,6 +448865,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -448527,7 +448931,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -448594,7 +448997,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -448629,6 +449031,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -448642,11 +449048,52 @@ 0, 0, 0, + 2 + ] + }, + { + "session": { + "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation", + "sourceId": "MDHXHK", + "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation", + "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Linux Foundation", + "Open Development" + ], + "tags": [ + "Open Source Software", + "FOSS", + "Best Practices", + "development", + "open", + "Best Practices", + "FOSS", + "Open Source Software" + ], + "language": "en", + "speakers": [ + "hart-montgomery" + ], + "eventId": "devcon-7", + "slot_start": 1731649800000, + "slot_end": 1731651600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -448732,6 +449179,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -448830,7 +449278,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -448893,7 +449340,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -449058,13 +449504,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -449075,49 +449519,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-infinite-diversity-in-infinite-combinations", - "sourceId": "3MNMHA", - "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations", - "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Plurality" - ], - "tags": [ - "Decentralization", - "Governance", - "Political systems" - ], - "language": "en", - "speakers": [ - "audrey-tang" - ], - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731391200000, - "slot_roomId": "main-stage", - "sources_youtubeId": "n3R4ze2hesk", - "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae", - "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -449455,6 +449862,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -449521,6 +449929,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -449542,7 +449951,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -449757,6 +450165,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -449819,6 +450228,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -449946,17 +450356,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -449986,11 +450393,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -450001,12 +450410,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-infinite-diversity-in-infinite-combinations", + "sourceId": "3MNMHA", + "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations", + "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Plurality" + ], + "tags": [ + "Decentralization", + "Governance", + "Political systems" + ], + "language": "en", + "speakers": [ + "audrey-tang" + ], + "eventId": "devcon-7", + "slot_start": 1731389400000, + "slot_end": 1731391200000, + "slot_roomId": "main-stage", + "sources_youtubeId": "n3R4ze2hesk", + "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae", + "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -450414,14 +450861,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -450429,41 +450874,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-lessons-learned-from-tor", - "sourceId": "ZHU7UQ", - "title": "Keynote: Lessons learned from Tor", - "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Human", - "rights" - ], - "tags": [ - "Anonymity", - "Privacy", - "Sustainability" - ], - "language": "en", - "speakers": [ - "roger-dingledine" - ], - "eventId": "devcon-7", - "slot_start": 1731651600000, - "slot_end": 1731654000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E" - }, - "vector": [ 0, 0, 0, @@ -450875,14 +451285,17 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -450896,7 +451309,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -451229,7 +451641,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -451320,7 +451731,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -451343,12 +451753,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -451356,11 +451768,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-lessons-learned-from-tor", + "sourceId": "ZHU7UQ", + "title": "Keynote: Lessons learned from Tor", + "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Human", + "rights" + ], + "tags": [ + "Anonymity", + "Privacy", + "Sustainability" + ], + "language": "en", + "speakers": [ + "roger-dingledine" + ], + "eventId": "devcon-7", + "slot_start": 1731651600000, + "slot_end": 1731654000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -451553,7 +452002,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -451765,11 +452213,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -451782,52 +452228,17 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy", - "sourceId": "NKMLNG", - "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy", - "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": true, - "doNotRecord": false, - "keywords": [ - "cypherpunk" - ], - "tags": [ - "Zk Rollups", - "Privacy", - "cypherpunk", - "Privacy", - "Zk Rollups" - ], - "language": "en", - "speakers": [ - "zac-williamson" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -452161,6 +452572,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -452251,7 +452663,7 @@ 0, 0, 0, - 6, + 2, 0, 0, 0, @@ -452484,6 +452896,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -452626,7 +453039,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -452674,7 +453086,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -452697,9 +453108,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -452712,11 +453125,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy", + "sourceId": "NKMLNG", + "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy", + "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": true, + "doNotRecord": false, + "keywords": [ + "cypherpunk" + ], + "tags": [ + "Zk Rollups", + "Privacy", + "cypherpunk", + "Privacy", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "zac-williamson" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -452939,7 +453389,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -453121,11 +453570,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -453133,54 +453580,12 @@ 0, 0, 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "keynote-making-sense-of-stablecoins", - "sourceId": "TDHR79", - "title": "Keynote: Making Sense of Stablecoins", - "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Stablecoins", - "Layer 2", - "RWA" - ], - "tags": [ - "Ethereum for Good", - "Payment", - "RWA" - ], - "language": "en", - "speakers": [ - "liam-horne" - ], - "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -453191,6 +453596,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -453498,7 +453904,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -453568,6 +453973,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -453615,6 +454021,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -453879,6 +454286,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -454037,7 +454445,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -454052,7 +454459,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -454062,6 +454468,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -454076,12 +454483,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-making-sense-of-stablecoins", + "sourceId": "TDHR79", + "title": "Keynote: Making Sense of Stablecoins", + "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Stablecoins", + "Layer 2", + "RWA" + ], + "tags": [ + "Ethereum for Good", + "Payment", + "RWA" + ], + "language": "en", + "speakers": [ + "liam-horne" + ], + "eventId": "devcon-7", + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -454403,6 +454847,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -454475,13 +454920,10 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -454490,44 +454932,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem", - "sourceId": "VQKXUH", - "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem", - "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": true, - "doNotRecord": false, - "keywords": [ - "ecosystem" - ], - "tags": [ - "Developer Infrastructure", - "DevEx", - "Tooling" - ], - "language": "en", - "speakers": [ - "patricio-palladino" - ], - "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731569400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -454906,41 +455313,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -455016,6 +455388,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -455030,6 +455403,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -455042,6 +455416,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -455284,7 +455659,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -455293,7 +455667,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -455317,7 +455690,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -455454,11 +455826,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -455467,9 +455841,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem", + "sourceId": "VQKXUH", + "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem", + "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": true, + "doNotRecord": false, + "keywords": [ + "ecosystem" + ], + "tags": [ + "Developer Infrastructure", + "DevEx", + "Tooling" + ], + "language": "en", + "speakers": [ + "patricio-palladino" + ], + "eventId": "devcon-7", + "slot_start": 1731567600000, + "slot_end": 1731569400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -455825,13 +456234,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -455842,49 +456249,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-programmable-cryptography-and-ethereum", - "sourceId": "MQ8T8Z", - "title": "Keynote: Programmable Cryptography and Ethereum", - "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "tags": [ - "Cryptography", - "Use cases of cryptography" - ], - "keywords": [ - "Programmable", - "Cryptography" - ], - "duration": 1517, - "language": "en", - "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9", - "sources_youtubeId": "UWPg_AmWtlw", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt", - "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.", - "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731400200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4", - "resources_slides": null, - "speakers": [ - "gubsheep" - ] - }, - "vector": [ 0, 0, 0, @@ -456072,7 +456436,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -456276,6 +456639,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -456284,6 +456648,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -456307,6 +456672,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -456637,7 +457003,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -456652,7 +457017,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -456816,11 +457180,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -456831,6 +457197,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-programmable-cryptography-and-ethereum", + "sourceId": "MQ8T8Z", + "title": "Keynote: Programmable Cryptography and Ethereum", + "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "tags": [ + "Cryptography", + "Use cases of cryptography" + ], + "keywords": [ + "Programmable", + "Cryptography" + ], + "duration": 1517, + "language": "en", + "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9", + "sources_youtubeId": "UWPg_AmWtlw", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt", + "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.", + "eventId": "devcon-7", + "slot_start": 1731398400000, + "slot_end": 1731400200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4", + "resources_slides": null, + "speakers": [ + "gubsheep" + ] + }, + "vector": [ 0, 0, 0, @@ -456841,6 +457250,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -457018,6 +457428,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -457188,9 +457599,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -457203,63 +457612,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-the-next-10-years-of-web3-in-africa", - "sourceId": "GSNQLC", - "title": "Keynote: The next 10 years of Web3 in Africa", - "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": true, - "doNotRecord": false, - "tags": [ - "Ethereum Roadmap", - "Use Cases", - "macro/micro economics", - "adoption", - "africa", - "mass", - "Ethereum Roadmap", - "macro/micro economics", - "Use Cases" - ], - "keywords": [ - "Africa", - "Mass adoption" - ], - "duration": 1531, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "NtkNYNvuu6w", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f64b3a168eb53542528d.vtt", - "transcript_text": " Leonardo Silva Reviewer:\" Elisabeth Buffard Hello everyone. Good to see you all today. I want to start off by asking who is here from the continent of Africa. Can you please raise your hand? Can you guys please stand up? Can you guys please stand up? Let's give this guy a big round of applause because like many of our folks have gone through crazy lengths to get themselves here with visas and everything. And this is the DEF CON that has the largest African builder concentration in one place. And my talk today is around what can we expect over the next 10 years in terms of crypto innovation and is very much inspired by a lot of what I've learned from all these folks and many more of what are the things that have been built today and what can we expect coming up. So two years ago at DEF CON, we established the fact that it's actually the crypto ecosystem that needs Africa to reach its full potential of reaching mass adoption and utility-driven building to scale it to billions of people. And we covered the fact that we are the most populous part of the world and we're growing really fast. That is going to be where all the young people in the world are going to be based at even today we have about 600 million Africans who are the end under the age of 14 that's out of 1.5 billion people and we also discussed around the technology rails that exist that how allowed us to basically skip generations of innovations such as mobile phones skipping landlines or mobile money where that has close to trillion dollars worth of transactions a year and we're jumping traditional banking with crypto. Two years ago when we discussed a lot of this, what was the reality is that mostly many of us were doing crypto to fiat transactions doing payments savings and storing resources or investing using predominantly centralized exchanges and a lot of centralized exchanges are actually not made to be banks they're trading platforms but we kind of figured a way to do that by having various liquidity providers like people like you and I providing liquidity on peer-to-peer their trading platforms. But we kind of figured a way to do that by having various liquidity providers like people like you and I, providing liquidity on peer-to-peer exchanges to drive a lot of the value for normal people to access traditional forms of banking that we need. So where are we today, two years from then? Well, the one reality is that in the traditional world we're still in the same place, that we are communicating value over walls, that the internet, as amazing as it's been at connecting us and letting communication flow, communication of value, which is through monetary systems, are actually very much gated. The internet continues to be very gated. The same way back in the days you would have an operator basically connecting two calls by manually calling the other side and seeing can we trust the other operator. That's the same process that we have today. So we are still working through walls in the traditional system. The other aspect of where we still are today is that a huge part of our economy is happening in the informal sector. That includes our GDP, our prominent GDP is backed by micro enterprises. A huge part of our employment is in the informal economy. A huge part of our GDP is also drive by the informal economy. A huge part of our GDP is also drived by the informal economy and also a lot of our money movement happens outside of the banking system. This is a very important context for us to understand why crypto is thriving so much on the continent. Another big also lens is that we have a systemic US dollar problem. Some of these numbers are a bit outdated but we're importing more than what we're exporting we're taking a lot of debt a lot of african countries debt has doubled in the last 10 years and we're paying that debt plus interest in dollars and we're trading with each other as neighbors using dollars and when our currencies fluctuate so much, then we move our money to dollars. So that creates a demand supply. And on the supply pressure, we have a lot of exports, remittance, people sending money. There's a thing called BRIC. Some of you guys might know about it. Around some countries deciding to settle outside of the dollar system, which is creating a bit less pressure on the dollar. And there's a lot of aid and loans that come in dollars. So what is the consequence of this? Is that basically the US dollars are being rationed by the central banks. The demand for dollars is higher than what they have there. So what you end up having is the bifurcation of the bank rate and the black market rate, or how I call it, the actual market rate um and in worse economies you see that being very large in well-managed economies it's very small but we're living in in parallel systems and also that makes the dollar a commodity so people do unnatural things in order to access dollars because the upside on trading the dollar is higher than the trade on the commodity itself, which creates very weird dysfunctions in our system. And some countries have also created rules of who can own dollars and how much you can transfer it. Until very recently, the Ethiopian government actually made it illegal, meaning you can go to prison for it, for holding more than $500 with you at any given point. Many of my friends' and family's houses were raided, just people looking for dollars. And that's because the central banks don't have enough dollars. And what that means, we borrow more money and then just rinse and repeat. So we have a systemic dollar problem. And so you look at that and say, okay, well, what is crypto doing? Well, fundamentally, what crypto has provided us is basically a digital version of the dollar, US dollar stable coins, that allow for large-scale liquidity coordination mechanism in the informal economy, where a lot of dollars have been circulating physically or through various networks like the Hawala networks that call each other and basically move numbers around. What has that allowed us is basically for early stage startups to be able to aggregate more liquidity than what a bank can in a very short period of time and then settle that payment in a much shorter period of time. And this has been a fundamental value proposition of crypto. So as a result of that, crypto has been thriving, it's been growing. Even in the bear market, crypto transactions have been growing on the continent. Chainalysis says we've had $125 billion worth of transactions last year. When I talk to the analysts and the builders, that's just the tip of the iceberg. There's much more dollars that's been transacted behind that. Nigeria of course is the second most popular place for crypto. And Nigeria, Ethiopia, Kenya, we search crypto online because it is solving fundamental problems for us. But this is not just centralized exchanges. This is happening in other rails that have been built. So actually, some of the builders here in this room have built some of these stacks. These are from the builders in Magma, from wallet infrastructure. So actually making like SDK wallets that you can embed into your fintech application or your crypto application. So you can use crypto and fiat. Aggregating liquidity on-chain and off- off chain which is actually not very easy to do and and simplify the on and off run process through that different types of wallets that are being created and all types of payments from b2b b2c b2b b2c serving like small businesses medium, medium-sized businesses, oil and gas companies, and even banks and payment service providers who are now using these startups to facilitate international payments. And people even issuing debit cards on top of your digital wallet in order to be able to pay online without having any limitations, because some of our banks say, I'm so sorry, you can only pay $10 a month. Well, if you have some resource, you want to buy a book from Amazon, how can you buy it with $10? Amazon is more expensive than that. So you're actually using crypto projects in order to do that. And so some of these projects are way advanced than where I see a lot of on and off ramps. And so, bluntly speaking, if DEF CON was held in one of the countries that were mentioned in Africa, the DEF CON organizing team can pay all their bills using crypto. All of us would basically be using our crypto to make payments with fiat without even needing a fiat wallet paying directly just using the applications that have been built today so there's been a lot of work that has happened in terms of making the user experience a lot easier and if you're curious about it just talk to many of the builders who are in this room so with that in mind what can we expect in the next 10 years what are some of the innovations that we can expect to have? Well, fundamentally, I think the most interesting part of crypto to me is bringing whole economies and powering them by decentralized systems. Part of that is basically changing the foundations of our existing economy, and part of it is like opening up new economic activities that we did not know existed before um and this is where i think ethereum comes in because that's the most robust and the most resilient decentralized system that we have right now so it's it's a beautiful merge here and when we think about rewriting a lot of the foundations of our economies we've got to think about both hyper globalizationglobalization and hyper-localization. We talked a lot about US dollar stablecoins, right? So the answer is not, let's dollarize the entire African economy. Everyone uses dollars, dollars for everyone. That's not the answer. I don't think that helps us and it doesn't help the global economy. So we've got to also think very locally. And one idea I'd love to dive deeper on is this idea of actually local currency stable coins. At the moment, when we think about stable coins, it's kind of synonymous with US dollar stable coins. How about actually having our Kenyan, Nigerian shillings, Nigerian naira, Ethiopian burr, a lot of our local currencies having a digital version of them on-chain. What does that allow? Well, on-chain forex. That makes it a lot more efficient. We'll double-click on that. Cheaper local payments. In a crazy way today, with blobs, it is cheaper to run transactions on a layer 2 at least 5 to 10 times than it is on mobile money or banking, which is quite crazy. Well, that doesn't mean blobs will scale infinitely, but it's just an interesting data point of what we can even do today. And the last part of the value here that we can think of at this stage is that it gives us programmable money, and that opens up a whole lot of opportunities and innovations that can happen. I really want to double click on the on-chain forex. Well today Kenya and Tanzania are neighboring countries right next to each other. We even speak similar languages and both our currencies are called shillings. But in order to make a payment from Kenya to Tanzania you actually have to convert it to the dollar. Dollar has to go through the trade system. It has to flow through London or New York or somewhere. It can take a few days, and depending on the volume, it can take even weeks. It's a very long process and long system. It doesn't make sense that we're having to do this as neighbors, right? With local stablecoins, you could potentially move from the Canadian shilling stablecoin to a Tanzanian shilling stable coin, both denominated in value against the dollar, but not actually touching the dollar. So this helps us move the US dollar from just being a medium of exchange to being a unit of account, which is a very interesting use case for it. So one way that can work is building a pair of liquidity where an importer is putting money into the pool from the Kenyan side and an exporter is pulling money out of it. And the person does the exact same thing on the Tanzanian front. And because every trade does not fully balance, you use dollars to basically rebalance the pool by adding local currency on the other side. This is just one model. I am sure we can come up with way more complex and more interesting models to structure this. But bringing forex on chain is one of the most interesting problems for us to solve using local stable coins. Now, when we think about that, we can think in a few million dollar value, or we can think about half economies. And I think the most important thing that we keep missing in the space when we look at the full potential of crypto is that we're not always looking at how can half an economy run on what we're building, and what needs to be true for us to get there. And the reason why I'm saying that is because, you know, many of you know M-Pesa, right? M-Pesa is one of the best success stories that has come out of Kenya. Half the Kenyan economy runs on M-Pesa. What M-Pesa is, is just a private ledger. It's a spreadsheet where they put some fiat in the bank, and the numbers move from different account names and at the end of the day it's basically settled at the bank layer that's somehow a version of what we're talking about but what we're talking about is putting that on chain and a much more open transparent system right for us to get to that level of scale at a much faster period we've got to think about from different principles and and one lens that I can think of is using government bonds to back our local stable coins. You convert the local bond into a real world asset that can either be fully collateralized through a CDP or a better model that we can come up with. And by the way, if you do, I'd love to chat with you. And basically use that to distribute local currency through existing and new rails around. The forex on-chain is one of the lowest-hanging fruit examples of where we can go, but we can bring so many other values to that. And in the future, it doesn't just need to be government bonds to do this. We can bring other types of assets assets like local land, productive land or protected land or gold and silver and precious metals. We're generating so much of that from Africa at the moment. Or we can do other types of commodities. This is such an open book in terms of what we back our local currencies with. Another pillar after local stablecoins that I love to chat about is simple finance as a stack. Now, here in the Ethereum world, we talk about decentralization a lot. Well, for us on the continent, decentralization is actually a very practical solution to a very practical problem. We have a lot of banking rails to build for hundreds of millions of people, and many of them have not been born yet. To do that, trying to build that in a monolithic way as a centralized company, as one piece, like Alipay or WeChat or Grab for 54 jurisdictions, and scale that in a very short period of time is almost impossible to execute. So the best way for us to do that that in a very short period of time, is almost impossible to execute. So the best way for us to do that, in my view, is just to build a connected web of tools. Different pieces of the Lego that form a financial stack that come together, that offer users a better experience and better options, right? I think building this in a much more decentralized way, to me, is the only way we can get to the level of scale that we need to achieve. So for us, it's actually a very practical solution, a practical way of getting there. And we can build interoperable monies with network effects. Remember the walls, the operator? We can just bypass that and keep moving value across different populations and people in that way. Create cash apps with simple user experience powered by crypto, but we don't even have to know that it's crypto. Today we have startups that are doing that, but we can scale that to infinity. And on the hyper-localization lens, there are many ways we can build around existing trust structures. Across many African countries, we have basically cooperatives and little communities of people. Some of us call them table banking, some of us call them chamas, where basically people pull money together to save and lend to each other. There's a strong trust infrastructure that exists to enable things like that. We don't have to reinvent trust from scratch. We can leverage those existing trust structures to build very resilient, hyper-local economies. And I think that should be part of our roadmap. And beyond, you know, so ultimately, it's just two people or two companies or two agents having normal financial transactions, right? No complexity, not much. We're not talking about crypto at the front end. This is all enabling that. Other areas of innovation that we can think about is like around credentialing, identity, reputation, credit scoring, bringing things that don't exist on chain to create trust on chain are some of the more interesting areas for us to experiment on. We don't have time to dive deep into many of these, and there's a lot more than other areas of innovation that we can build in the next 10 years, but talk to the builders around the table. And the other areas bringing assets on chain, such as real estate. We talked about bonds earlier, but different types of commodities, energy, power generating structures that we need to fund and actually revenue generating. We can experiment with so many of these that actually powers the fundamentals of our economies. So with all these ideas and directions that we can go, you might be wondering, how do I help? How do I connect? How do I participate in this? Well, the first is it's an invitation. It's actually an invitation because there's a lot of building happening on the continent, whether we have a lot of builders coming to DEF CON or not. So it's an invitation for you all from infrastructure, from research, from different ecosystems and chains, from capital allocation, from mentorship and support, from actually working with some of the smartest people on the planet. There are many ways you can plug it into the movement that is happening in Africa. And of course, why not bring DEF CON to Africa in two years' time? Who's down for something like that here? Right? Well, yeah, I think that would be super cool, and you guys will have a blast joining DEF CON there. But it's actually not about having another big event on the continent. It's actually, it gives you a much deeper context to go and see this in practice. It is very, very hard to explain how broken the world gardens are until you actually go and experience it in person. Or it's very hard for me to explain to you like what seamless user experience for crypto looks like without actually going and experiencing and making a whole lot of payments and living your life using your crypto wallet without touching physical bills, right? So it's an invitation for you to actually be part of the movement and work that we have. And lastly, because all the Ethereum events that have happened around the world have happened in places where it's just very hard to get visas, right. So to get 177 folks here, man, that was like a lot of work and it's been a lot of collective effort. And there are hundreds and thousands more that you would absolutely enjoy connecting with and learning with and learning from. And so you're invited home. Welcome, guys. All right. That was an awesome presentation, you guys. We have a Q&A session. So anyone want to put a question, that's the QR right there. Just scan it and put a question there. We have a lot for you, brother. Yes. Let's take a look at which one you want to answer first. We can talk about the non-financial use cases. We can talk about the non-financial use cases. We talked about them later on. Yeah, this talk focused a lot on finance because it's just a lot to unpack. And each topic that we talked around, credentialing, around bringing assets on-chain, and credit scoring, and gaming, and communication, there's a lot to unpack there. I will actually invite you guys to talk to some of our builders here to understand a lot of the nuances. But at the moment, 500 million Africans don't have any form of legal ID. And the best that some of our countries are doing is basically having a data center in one location or two locations and putting the entire population's data there. It's like a honeypot of sovereign data. That's not the most secure way to do it, in my opinion. the entire population's data there. It's like a honeypot of sovereign data, right? That's not the most secure way to do it, in my opinion. So I think there's a lot of ways we can innovate around that. KYC is one that really came up, like transferable KYC across multiple tools. So the list goes on. So the invitation is to actually talk to the builders in the room. Any questions you want to answer? We have a lot more here. All right. What do you see Africa becoming? What do you see Africa becoming a well-coordinated roadmap? I want to talk about regulation. All right, let's go. Because that continues to be a hot topic. And it's really important to us because many of our innovations are interfacing the traditional world with the crypto world because that that door needs to be very fluid it needs to allow money to keep moving back and forth for a long period of time and until we bring it on chain um and i think that's a that's a very important problem so i talked to a bunch of regulators many of the builders here talk to many regulators there's there's curiosity, there's some fear because crypto can be a path for capital flight. A lot of value to live in a short period of time. And that's an actual risk. And some of them don't even understand the fundamentals of this technology. So what we end up having is some countries like South Africa saying, crypto is legal. It's a commodity. We will allow it and so we have a lot of builders working there some countries creating environments for experimentation like sandboxes and actually this is a bit of a controversial view but I think creating some sort of tax revenue from crypto transactions for governments is a potentially positive thing if it's done well, because it moves this category from a risk basis to an income generating category. And bringing local stable coins on chain is, I think, one of the biggest value props for governments, because what it does is it creates a much more efficient capital markets for dollars and bonds it brings dollars in and helps reduce the dollar pressure for local trade that can happen so they have an incentive to see something like that but there's a lot of people here doing the hard work of actually informing regulators and we keep building like we keep building even with gray area we keep building like the show doesn't stop. And I think that's something some of us in, like, the Western world find it hard to kind of navigate around, is because, like, even when Nigeria makes crypto illegal, like, we still have close to 15% of the country's GDP, like, proportion transactions happening in crypto, right? So, yeah, it makes you kind of wonder what some of those kind of guidelines can actually have an effect. I think we have about one or two questions more. Let's see what we want to answer. Am I hiring? Are you hiring? I mean, I don't know, guys. We can jam outside after this and recruit more folks to help answer the question. But yeah, I guess what needs to happen before a DEF CON happens there is there's a lot we've got to do on the continent. We have many communities doing real work. They need a lot of support and engagement. So I think that will bring a lot of value. We need to have more hackathons and builders. But, like, I think our builder community, like, the startups that we have there are, from a user experience perspective, in my opinion, are, like, way ahead from what we keep talking about around usability making crypto usable for daily life like whenever I'm in many African countries like I don't use my card, I don't use cash I'm just like paying all types of bills using my crypto account and I think that's super cool and that's amazing so like even the bill of community alone is enough to host you all. All right. Give a round of applause for the speaker. Thank you.", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8", - "resources_slides": null, - "speakers": [ - "yoseph-ayele" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -457653,6 +458011,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -458071,7 +458430,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -458150,8 +458508,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -458186,13 +458542,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -458205,13 +458562,64 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-the-next-10-years-of-web3-in-africa", + "sourceId": "GSNQLC", + "title": "Keynote: The next 10 years of Web3 in Africa", + "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": true, + "doNotRecord": false, + "tags": [ + "Ethereum Roadmap", + "Use Cases", + "macro/micro economics", + "adoption", + "africa", + "mass", + "Ethereum Roadmap", + "macro/micro economics", + "Use Cases" + ], + "keywords": [ + "Africa", + "Mass adoption", + "" + ], + "duration": 1531, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "NtkNYNvuu6w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f64b3a168eb53542528d.vtt", + "transcript_text": " Leonardo Silva Reviewer:\" Elisabeth Buffard Hello everyone. Good to see you all today. I want to start off by asking who is here from the continent of Africa. Can you please raise your hand? Can you guys please stand up? Can you guys please stand up? Let's give this guy a big round of applause because like many of our folks have gone through crazy lengths to get themselves here with visas and everything. And this is the DEF CON that has the largest African builder concentration in one place. And my talk today is around what can we expect over the next 10 years in terms of crypto innovation and is very much inspired by a lot of what I've learned from all these folks and many more of what are the things that have been built today and what can we expect coming up. So two years ago at DEF CON, we established the fact that it's actually the crypto ecosystem that needs Africa to reach its full potential of reaching mass adoption and utility-driven building to scale it to billions of people. And we covered the fact that we are the most populous part of the world and we're growing really fast. That is going to be where all the young people in the world are going to be based at even today we have about 600 million Africans who are the end under the age of 14 that's out of 1.5 billion people and we also discussed around the technology rails that exist that how allowed us to basically skip generations of innovations such as mobile phones skipping landlines or mobile money where that has close to trillion dollars worth of transactions a year and we're jumping traditional banking with crypto. Two years ago when we discussed a lot of this, what was the reality is that mostly many of us were doing crypto to fiat transactions doing payments savings and storing resources or investing using predominantly centralized exchanges and a lot of centralized exchanges are actually not made to be banks they're trading platforms but we kind of figured a way to do that by having various liquidity providers like people like you and I providing liquidity on peer-to-peer their trading platforms. But we kind of figured a way to do that by having various liquidity providers like people like you and I, providing liquidity on peer-to-peer exchanges to drive a lot of the value for normal people to access traditional forms of banking that we need. So where are we today, two years from then? Well, the one reality is that in the traditional world we're still in the same place, that we are communicating value over walls, that the internet, as amazing as it's been at connecting us and letting communication flow, communication of value, which is through monetary systems, are actually very much gated. The internet continues to be very gated. The same way back in the days you would have an operator basically connecting two calls by manually calling the other side and seeing can we trust the other operator. That's the same process that we have today. So we are still working through walls in the traditional system. The other aspect of where we still are today is that a huge part of our economy is happening in the informal sector. That includes our GDP, our prominent GDP is backed by micro enterprises. A huge part of our employment is in the informal economy. A huge part of our GDP is also drive by the informal economy. A huge part of our GDP is also drived by the informal economy and also a lot of our money movement happens outside of the banking system. This is a very important context for us to understand why crypto is thriving so much on the continent. Another big also lens is that we have a systemic US dollar problem. Some of these numbers are a bit outdated but we're importing more than what we're exporting we're taking a lot of debt a lot of african countries debt has doubled in the last 10 years and we're paying that debt plus interest in dollars and we're trading with each other as neighbors using dollars and when our currencies fluctuate so much, then we move our money to dollars. So that creates a demand supply. And on the supply pressure, we have a lot of exports, remittance, people sending money. There's a thing called BRIC. Some of you guys might know about it. Around some countries deciding to settle outside of the dollar system, which is creating a bit less pressure on the dollar. And there's a lot of aid and loans that come in dollars. So what is the consequence of this? Is that basically the US dollars are being rationed by the central banks. The demand for dollars is higher than what they have there. So what you end up having is the bifurcation of the bank rate and the black market rate, or how I call it, the actual market rate um and in worse economies you see that being very large in well-managed economies it's very small but we're living in in parallel systems and also that makes the dollar a commodity so people do unnatural things in order to access dollars because the upside on trading the dollar is higher than the trade on the commodity itself, which creates very weird dysfunctions in our system. And some countries have also created rules of who can own dollars and how much you can transfer it. Until very recently, the Ethiopian government actually made it illegal, meaning you can go to prison for it, for holding more than $500 with you at any given point. Many of my friends' and family's houses were raided, just people looking for dollars. And that's because the central banks don't have enough dollars. And what that means, we borrow more money and then just rinse and repeat. So we have a systemic dollar problem. And so you look at that and say, okay, well, what is crypto doing? Well, fundamentally, what crypto has provided us is basically a digital version of the dollar, US dollar stable coins, that allow for large-scale liquidity coordination mechanism in the informal economy, where a lot of dollars have been circulating physically or through various networks like the Hawala networks that call each other and basically move numbers around. What has that allowed us is basically for early stage startups to be able to aggregate more liquidity than what a bank can in a very short period of time and then settle that payment in a much shorter period of time. And this has been a fundamental value proposition of crypto. So as a result of that, crypto has been thriving, it's been growing. Even in the bear market, crypto transactions have been growing on the continent. Chainalysis says we've had $125 billion worth of transactions last year. When I talk to the analysts and the builders, that's just the tip of the iceberg. There's much more dollars that's been transacted behind that. Nigeria of course is the second most popular place for crypto. And Nigeria, Ethiopia, Kenya, we search crypto online because it is solving fundamental problems for us. But this is not just centralized exchanges. This is happening in other rails that have been built. So actually, some of the builders here in this room have built some of these stacks. These are from the builders in Magma, from wallet infrastructure. So actually making like SDK wallets that you can embed into your fintech application or your crypto application. So you can use crypto and fiat. Aggregating liquidity on-chain and off- off chain which is actually not very easy to do and and simplify the on and off run process through that different types of wallets that are being created and all types of payments from b2b b2c b2b b2c serving like small businesses medium, medium-sized businesses, oil and gas companies, and even banks and payment service providers who are now using these startups to facilitate international payments. And people even issuing debit cards on top of your digital wallet in order to be able to pay online without having any limitations, because some of our banks say, I'm so sorry, you can only pay $10 a month. Well, if you have some resource, you want to buy a book from Amazon, how can you buy it with $10? Amazon is more expensive than that. So you're actually using crypto projects in order to do that. And so some of these projects are way advanced than where I see a lot of on and off ramps. And so, bluntly speaking, if DEF CON was held in one of the countries that were mentioned in Africa, the DEF CON organizing team can pay all their bills using crypto. All of us would basically be using our crypto to make payments with fiat without even needing a fiat wallet paying directly just using the applications that have been built today so there's been a lot of work that has happened in terms of making the user experience a lot easier and if you're curious about it just talk to many of the builders who are in this room so with that in mind what can we expect in the next 10 years what are some of the innovations that we can expect to have? Well, fundamentally, I think the most interesting part of crypto to me is bringing whole economies and powering them by decentralized systems. Part of that is basically changing the foundations of our existing economy, and part of it is like opening up new economic activities that we did not know existed before um and this is where i think ethereum comes in because that's the most robust and the most resilient decentralized system that we have right now so it's it's a beautiful merge here and when we think about rewriting a lot of the foundations of our economies we've got to think about both hyper globalizationglobalization and hyper-localization. We talked a lot about US dollar stablecoins, right? So the answer is not, let's dollarize the entire African economy. Everyone uses dollars, dollars for everyone. That's not the answer. I don't think that helps us and it doesn't help the global economy. So we've got to also think very locally. And one idea I'd love to dive deeper on is this idea of actually local currency stable coins. At the moment, when we think about stable coins, it's kind of synonymous with US dollar stable coins. How about actually having our Kenyan, Nigerian shillings, Nigerian naira, Ethiopian burr, a lot of our local currencies having a digital version of them on-chain. What does that allow? Well, on-chain forex. That makes it a lot more efficient. We'll double-click on that. Cheaper local payments. In a crazy way today, with blobs, it is cheaper to run transactions on a layer 2 at least 5 to 10 times than it is on mobile money or banking, which is quite crazy. Well, that doesn't mean blobs will scale infinitely, but it's just an interesting data point of what we can even do today. And the last part of the value here that we can think of at this stage is that it gives us programmable money, and that opens up a whole lot of opportunities and innovations that can happen. I really want to double click on the on-chain forex. Well today Kenya and Tanzania are neighboring countries right next to each other. We even speak similar languages and both our currencies are called shillings. But in order to make a payment from Kenya to Tanzania you actually have to convert it to the dollar. Dollar has to go through the trade system. It has to flow through London or New York or somewhere. It can take a few days, and depending on the volume, it can take even weeks. It's a very long process and long system. It doesn't make sense that we're having to do this as neighbors, right? With local stablecoins, you could potentially move from the Canadian shilling stablecoin to a Tanzanian shilling stable coin, both denominated in value against the dollar, but not actually touching the dollar. So this helps us move the US dollar from just being a medium of exchange to being a unit of account, which is a very interesting use case for it. So one way that can work is building a pair of liquidity where an importer is putting money into the pool from the Kenyan side and an exporter is pulling money out of it. And the person does the exact same thing on the Tanzanian front. And because every trade does not fully balance, you use dollars to basically rebalance the pool by adding local currency on the other side. This is just one model. I am sure we can come up with way more complex and more interesting models to structure this. But bringing forex on chain is one of the most interesting problems for us to solve using local stable coins. Now, when we think about that, we can think in a few million dollar value, or we can think about half economies. And I think the most important thing that we keep missing in the space when we look at the full potential of crypto is that we're not always looking at how can half an economy run on what we're building, and what needs to be true for us to get there. And the reason why I'm saying that is because, you know, many of you know M-Pesa, right? M-Pesa is one of the best success stories that has come out of Kenya. Half the Kenyan economy runs on M-Pesa. What M-Pesa is, is just a private ledger. It's a spreadsheet where they put some fiat in the bank, and the numbers move from different account names and at the end of the day it's basically settled at the bank layer that's somehow a version of what we're talking about but what we're talking about is putting that on chain and a much more open transparent system right for us to get to that level of scale at a much faster period we've got to think about from different principles and and one lens that I can think of is using government bonds to back our local stable coins. You convert the local bond into a real world asset that can either be fully collateralized through a CDP or a better model that we can come up with. And by the way, if you do, I'd love to chat with you. And basically use that to distribute local currency through existing and new rails around. The forex on-chain is one of the lowest-hanging fruit examples of where we can go, but we can bring so many other values to that. And in the future, it doesn't just need to be government bonds to do this. We can bring other types of assets assets like local land, productive land or protected land or gold and silver and precious metals. We're generating so much of that from Africa at the moment. Or we can do other types of commodities. This is such an open book in terms of what we back our local currencies with. Another pillar after local stablecoins that I love to chat about is simple finance as a stack. Now, here in the Ethereum world, we talk about decentralization a lot. Well, for us on the continent, decentralization is actually a very practical solution to a very practical problem. We have a lot of banking rails to build for hundreds of millions of people, and many of them have not been born yet. To do that, trying to build that in a monolithic way as a centralized company, as one piece, like Alipay or WeChat or Grab for 54 jurisdictions, and scale that in a very short period of time is almost impossible to execute. So the best way for us to do that that in a very short period of time, is almost impossible to execute. So the best way for us to do that, in my view, is just to build a connected web of tools. Different pieces of the Lego that form a financial stack that come together, that offer users a better experience and better options, right? I think building this in a much more decentralized way, to me, is the only way we can get to the level of scale that we need to achieve. So for us, it's actually a very practical solution, a practical way of getting there. And we can build interoperable monies with network effects. Remember the walls, the operator? We can just bypass that and keep moving value across different populations and people in that way. Create cash apps with simple user experience powered by crypto, but we don't even have to know that it's crypto. Today we have startups that are doing that, but we can scale that to infinity. And on the hyper-localization lens, there are many ways we can build around existing trust structures. Across many African countries, we have basically cooperatives and little communities of people. Some of us call them table banking, some of us call them chamas, where basically people pull money together to save and lend to each other. There's a strong trust infrastructure that exists to enable things like that. We don't have to reinvent trust from scratch. We can leverage those existing trust structures to build very resilient, hyper-local economies. And I think that should be part of our roadmap. And beyond, you know, so ultimately, it's just two people or two companies or two agents having normal financial transactions, right? No complexity, not much. We're not talking about crypto at the front end. This is all enabling that. Other areas of innovation that we can think about is like around credentialing, identity, reputation, credit scoring, bringing things that don't exist on chain to create trust on chain are some of the more interesting areas for us to experiment on. We don't have time to dive deep into many of these, and there's a lot more than other areas of innovation that we can build in the next 10 years, but talk to the builders around the table. And the other areas bringing assets on chain, such as real estate. We talked about bonds earlier, but different types of commodities, energy, power generating structures that we need to fund and actually revenue generating. We can experiment with so many of these that actually powers the fundamentals of our economies. So with all these ideas and directions that we can go, you might be wondering, how do I help? How do I connect? How do I participate in this? Well, the first is it's an invitation. It's actually an invitation because there's a lot of building happening on the continent, whether we have a lot of builders coming to DEF CON or not. So it's an invitation for you all from infrastructure, from research, from different ecosystems and chains, from capital allocation, from mentorship and support, from actually working with some of the smartest people on the planet. There are many ways you can plug it into the movement that is happening in Africa. And of course, why not bring DEF CON to Africa in two years' time? Who's down for something like that here? Right? Well, yeah, I think that would be super cool, and you guys will have a blast joining DEF CON there. But it's actually not about having another big event on the continent. It's actually, it gives you a much deeper context to go and see this in practice. It is very, very hard to explain how broken the world gardens are until you actually go and experience it in person. Or it's very hard for me to explain to you like what seamless user experience for crypto looks like without actually going and experiencing and making a whole lot of payments and living your life using your crypto wallet without touching physical bills, right? So it's an invitation for you to actually be part of the movement and work that we have. And lastly, because all the Ethereum events that have happened around the world have happened in places where it's just very hard to get visas, right. So to get 177 folks here, man, that was like a lot of work and it's been a lot of collective effort. And there are hundreds and thousands more that you would absolutely enjoy connecting with and learning with and learning from. And so you're invited home. Welcome, guys. All right. That was an awesome presentation, you guys. We have a Q&A session. So anyone want to put a question, that's the QR right there. Just scan it and put a question there. We have a lot for you, brother. Yes. Let's take a look at which one you want to answer first. We can talk about the non-financial use cases. We can talk about the non-financial use cases. We talked about them later on. Yeah, this talk focused a lot on finance because it's just a lot to unpack. And each topic that we talked around, credentialing, around bringing assets on-chain, and credit scoring, and gaming, and communication, there's a lot to unpack there. I will actually invite you guys to talk to some of our builders here to understand a lot of the nuances. But at the moment, 500 million Africans don't have any form of legal ID. And the best that some of our countries are doing is basically having a data center in one location or two locations and putting the entire population's data there. It's like a honeypot of sovereign data. That's not the most secure way to do it, in my opinion. the entire population's data there. It's like a honeypot of sovereign data, right? That's not the most secure way to do it, in my opinion. So I think there's a lot of ways we can innovate around that. KYC is one that really came up, like transferable KYC across multiple tools. So the list goes on. So the invitation is to actually talk to the builders in the room. Any questions you want to answer? We have a lot more here. All right. What do you see Africa becoming? What do you see Africa becoming a well-coordinated roadmap? I want to talk about regulation. All right, let's go. Because that continues to be a hot topic. And it's really important to us because many of our innovations are interfacing the traditional world with the crypto world because that that door needs to be very fluid it needs to allow money to keep moving back and forth for a long period of time and until we bring it on chain um and i think that's a that's a very important problem so i talked to a bunch of regulators many of the builders here talk to many regulators there's there's curiosity, there's some fear because crypto can be a path for capital flight. A lot of value to live in a short period of time. And that's an actual risk. And some of them don't even understand the fundamentals of this technology. So what we end up having is some countries like South Africa saying, crypto is legal. It's a commodity. We will allow it and so we have a lot of builders working there some countries creating environments for experimentation like sandboxes and actually this is a bit of a controversial view but I think creating some sort of tax revenue from crypto transactions for governments is a potentially positive thing if it's done well, because it moves this category from a risk basis to an income generating category. And bringing local stable coins on chain is, I think, one of the biggest value props for governments, because what it does is it creates a much more efficient capital markets for dollars and bonds it brings dollars in and helps reduce the dollar pressure for local trade that can happen so they have an incentive to see something like that but there's a lot of people here doing the hard work of actually informing regulators and we keep building like we keep building even with gray area we keep building like the show doesn't stop. And I think that's something some of us in, like, the Western world find it hard to kind of navigate around, is because, like, even when Nigeria makes crypto illegal, like, we still have close to 15% of the country's GDP, like, proportion transactions happening in crypto, right? So, yeah, it makes you kind of wonder what some of those kind of guidelines can actually have an effect. I think we have about one or two questions more. Let's see what we want to answer. Am I hiring? Are you hiring? I mean, I don't know, guys. We can jam outside after this and recruit more folks to help answer the question. But yeah, I guess what needs to happen before a DEF CON happens there is there's a lot we've got to do on the continent. We have many communities doing real work. They need a lot of support and engagement. So I think that will bring a lot of value. We need to have more hackathons and builders. But, like, I think our builder community, like, the startups that we have there are, from a user experience perspective, in my opinion, are, like, way ahead from what we keep talking about around usability making crypto usable for daily life like whenever I'm in many African countries like I don't use my card, I don't use cash I'm just like paying all types of bills using my crypto account and I think that's super cool and that's amazing so like even the bill of community alone is enough to host you all. All right. Give a round of applause for the speaker. Thank you.", + "eventId": "devcon-7", + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8", + "resources_slides": null, + "speakers": [ + "yoseph-ayele" + ] + }, + "vector": [ 0, 0, - 2, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -458390,7 +458798,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -458554,7 +458961,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -458562,7 +458968,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -458571,46 +458976,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-the-real-state-of-l2s", - "sourceId": "HCXUU8", - "title": "Keynote: The REAL state of L2s", - "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": true, - "doNotRecord": false, - "keywords": [ - "L2Risks", - "Myths&Reality" - ], - "tags": [ - "Architecture", - "Layer 2s", - "Best Practices", - "myths", - "reality", - "Architecture", - "Best Practices", - "Layer 2s" - ], - "language": "en", - "speakers": [ - "bartek-kiepuszewski" - ], - "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0" - }, - "vector": [ 0, 0, 0, @@ -458618,7 +458983,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -458636,6 +459000,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -459045,7 +459410,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -459071,6 +459435,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459149,6 +459514,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -459183,6 +459550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459203,6 +459571,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459381,11 +459750,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -459412,11 +459781,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -459551,6 +459918,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459558,6 +459926,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -459566,6 +459935,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-the-real-state-of-l2s", + "sourceId": "HCXUU8", + "title": "Keynote: The REAL state of L2s", + "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": true, + "doNotRecord": false, + "keywords": [ + "L2Risks", + "Myths&Reality" + ], + "tags": [ + "Architecture", + "Layer 2s", + "Best Practices", + "myths", + "reality", + "Architecture", + "Best Practices", + "Layer 2s" + ], + "language": "en", + "speakers": [ + "bartek-kiepuszewski" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0" + }, + "vector": [ 0, 0, 0, @@ -459573,6 +459982,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -459597,7 +460007,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459749,7 +460158,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459912,7 +460320,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459921,7 +460328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -459929,40 +460335,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-the-universal-cryptographic-adapter", - "sourceId": "R9X9ZG", - "title": "Keynote: The Universal Cryptographic Adapter", - "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "keywords": [ - "None" - ], - "tags": [ - "Not financial", - "Permissionless", - "ZKP" - ], - "language": "en", - "speakers": [ - "justin-glibert" - ], - "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg" - }, - "vector": [ 0, 0, 0, @@ -459973,7 +460345,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -460040,6 +460411,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -460149,7 +460521,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -460378,6 +460749,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460408,9 +460780,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -460591,6 +460965,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460742,6 +461117,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460777,7 +461153,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -460894,7 +461269,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -460906,6 +461280,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460914,6 +461289,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -460921,6 +461297,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-the-universal-cryptographic-adapter", + "sourceId": "R9X9ZG", + "title": "Keynote: The Universal Cryptographic Adapter", + "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "keywords": [ + "None" + ], + "tags": [ + "Not financial", + "Permissionless", + "ZKP" + ], + "language": "en", + "speakers": [ + "justin-glibert" + ], + "eventId": "devcon-7", + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg" + }, + "vector": [ 0, 0, 0, @@ -460931,6 +461341,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -460941,7 +461352,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -461108,6 +461518,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -461267,8 +461678,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -461281,62 +461690,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-title-redacted", - "sourceId": "8GH8TR", - "title": "Keynote: [title redacted]", - "description": "[description redacted]", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": true, - "doNotRecord": false, - "tags": [ - "Consensus", - "Ethereum Roadmap", - "cryptoeconomy", - "Consensus", - "Core Protocol", - "Ethereum Roadmap" - ], - "keywords": [ - "beacon chain", - "research", - "cryptoeconomics" - ], - "duration": 1553, - "language": "en", - "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e", - "sources_youtubeId": "Plvy7fgFCm4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU", - "resources_slides": null, - "speakers": [ - "justin-drake" - ] - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -461764,9 +462117,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -461799,6 +462149,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -461915,6 +462266,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -461961,6 +462313,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -462073,7 +462426,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -462087,7 +462439,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462262,7 +462613,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462289,6 +462639,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -462301,10 +462653,59 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-title-redacted", + "sourceId": "8GH8TR", + "title": "Keynote: [title redacted]", + "description": "[description redacted]", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": true, + "doNotRecord": false, + "tags": [ + "Consensus", + "Ethereum Roadmap", + "cryptoeconomy", + "Consensus", + "Core Protocol", + "Ethereum Roadmap" + ], + "keywords": [ + "beacon chain", + "research", + "cryptoeconomics" + ], + "duration": 1553, + "language": "en", + "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e", + "sources_youtubeId": "Plvy7fgFCm4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU", + "resources_slides": null, + "speakers": [ + "justin-drake" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -462468,7 +462869,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462630,7 +463030,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462639,7 +463038,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -462647,46 +463045,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-unifying-ethereum-through-intents-and-erc-7683", - "sourceId": "WHYZCD", - "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683", - "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": true, - "doNotRecord": false, - "keywords": [ - "ERC-7683", - "Interoperability" - ], - "tags": [ - "Cross-L2", - "UI/UX", - "Intents", - "interoperability", - "erc-7683", - "Cross-L2", - "Intents", - "UI/UX" - ], - "language": "en", - "speakers": [ - "hart-lambur" - ], - "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY" - }, - "vector": [ 0, 0, 0, @@ -462694,7 +463052,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -462781,6 +463138,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -463091,6 +463449,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -463104,6 +463463,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463123,7 +463483,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -463279,6 +463638,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463481,7 +463841,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -463599,7 +463958,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -463628,7 +463986,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -463649,6 +464006,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463657,6 +464015,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -463664,6 +464023,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-unifying-ethereum-through-intents-and-erc-7683", + "sourceId": "WHYZCD", + "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683", + "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": true, + "doNotRecord": false, + "keywords": [ + "ERC-7683", + "Interoperability" + ], + "tags": [ + "Cross-L2", + "UI/UX", + "Intents", + "interoperability", + "erc-7683", + "Cross-L2", + "Intents", + "UI/UX" + ], + "language": "en", + "speakers": [ + "hart-lambur" + ], + "eventId": "devcon-7", + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY" + }, + "vector": [ 0, 0, 0, @@ -463671,6 +464070,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -463818,7 +464218,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -463988,7 +464387,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -463996,7 +464394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -464005,48 +464402,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "keynote-world-politics-world-building", - "sourceId": "ERQKUX", - "title": "Keynote: World Politics, World Building", - "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Academic", - "featured": true, - "doNotRecord": false, - "keywords": [ - "World Building", - "Technology", - "Geopolitics" - ], - "tags": [], - "language": "en", - "speakers": [ - "bruno-macaes" - ], - "eventId": "devcon-7", - "slot_start": 1731652200000, - "slot_end": 1731654000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -464146,6 +464501,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -464474,7 +464830,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -464506,9 +464861,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -464622,6 +464979,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -464650,6 +465008,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -464839,6 +465198,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -465008,6 +465368,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -465015,6 +465376,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -465023,12 +465385,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "keynote-world-politics-world-building", + "sourceId": "ERQKUX", + "title": "Keynote: World Politics, World Building", + "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Academic", + "featured": true, + "doNotRecord": false, + "keywords": [ + "World Building", + "Technology", + "Geopolitics" + ], + "tags": [], + "language": "en", + "speakers": [ + "bruno-macaes" + ], + "eventId": "devcon-7", + "slot_start": 1731652200000, + "slot_end": 1731654000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -465340,7 +465735,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -465351,57 +465745,15 @@ 0, 0, 0, - 2, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "kickstarting-impact-funding-with-hypercerts", - "sourceId": "VGZ7PP", - "title": "Kickstarting impact funding with hypercerts", - "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.", - "track": "Real World Ethereum", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Impact", - "Funding" - ], - "tags": [ - "DevEx", - "RPGF", - "Best Practices", - "funding", - "Best Practices", - "DevEx", - "RPGF" - ], - "language": "en", - "speakers": [ - "holke-brammer", - "bitbeckers" - ], - "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731582000000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -465504,6 +465856,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -465833,8 +466186,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -466164,8 +466515,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -466375,6 +466724,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -466385,15 +466735,57 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "kickstarting-impact-funding-with-hypercerts", + "sourceId": "VGZ7PP", + "title": "Kickstarting impact funding with hypercerts", + "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.", + "track": "Real World Ethereum", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Impact", + "Funding" + ], + "tags": [ + "DevEx", + "RPGF", + "Best Practices", + "funding", + "Best Practices", + "DevEx", + "RPGF" + ], + "language": "en", + "speakers": [ + "holke-brammer", + "bitbeckers" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731582000000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -466401,7 +466793,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -466448,7 +466839,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -466696,11 +467086,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -466713,32 +467101,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ktv-attestation-winners", - "sourceId": "MP9UQV", - "title": "KTV Attestation Winners", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o" - }, - "vector": [ 0, 0, 0, @@ -466748,14 +467110,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -466865,6 +467219,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -467196,6 +467552,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -467431,6 +467789,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -467477,6 +467836,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -467724,9 +468084,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -467739,6 +468101,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ktv-attestation-winners", + "sourceId": "MP9UQV", + "title": "KTV Attestation Winners", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o" + }, + "vector": [ 0, 0, 0, @@ -467748,6 +468136,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -468041,10 +468430,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -468057,42 +468444,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ktv-winners", - "sourceId": "UYQFMA", - "title": "KTV Winners", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731501000000, - "slot_end": 1731501900000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, 0, 0, 0, @@ -469082,8 +469433,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -469096,6 +469449,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ktv-winners", + "sourceId": "UYQFMA", + "title": "KTV Winners", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731501000000, + "slot_end": 1731501900000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y" + }, + "vector": [ 0, 0, 0, @@ -469105,6 +469484,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -469385,10 +469765,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -469401,52 +469779,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state", - "sourceId": "ERQ7N3", - "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State", - "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "DevEx", - "Rollups" - ], - "keywords": [ - "RIP", - "L1SLOAD", - "Precompile" - ], - "duration": 5064, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "R9-QpN-hr6w", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731400200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E", - "resources_slides": null, - "speakers": [ - "peter-garamvolgyi", - "rh" - ] - }, - "vector": [ 0, 0, 0, @@ -469454,7 +469786,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -469887,8 +470218,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -470216,7 +470545,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -470228,7 +470556,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -470240,7 +470567,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -470455,8 +470781,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -470469,6 +470797,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state", + "sourceId": "ERQ7N3", + "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State", + "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Developer Infrastructure", + "DevEx", + "Rollups" + ], + "keywords": [ + "RIP", + "L1SLOAD", + "Precompile" + ], + "duration": 5064, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "R9-QpN-hr6w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731394800000, + "slot_end": 1731400200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E", + "resources_slides": null, + "speakers": [ + "peter-garamvolgyi", + "rh" + ] + }, + "vector": [ 0, 0, 0, @@ -470476,6 +470850,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -470750,9 +471125,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -470765,46 +471138,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l1sload-precompile-read-l1-state-from-your-l2-contract", - "sourceId": "VRXWFH", - "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract", - "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "RIPs", - "L1SLOAD", - "Precompile" - ], - "tags": [ - "Cross-L2", - "Developer Infrastructure", - "DevEx", - "precompile", - "Cross-L2", - "Developer Infrastructure", - "DevEx" - ], - "language": "en", - "speakers": [ - "peter-garamvolgyi" - ], - "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs" - }, - "vector": [ 0, 0, 0, @@ -470812,7 +471145,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -470953,6 +471285,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -471245,7 +471579,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -471283,6 +471616,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471294,6 +471628,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471305,6 +471640,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -471574,7 +471910,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471598,7 +471933,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471746,7 +472080,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -471817,7 +472150,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -471830,6 +472165,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "l1sload-precompile-read-l1-state-from-your-l2-contract", + "sourceId": "VRXWFH", + "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract", + "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "RIPs", + "L1SLOAD", + "Precompile" + ], + "tags": [ + "Cross-L2", + "Developer Infrastructure", + "DevEx", + "precompile", + "Cross-L2", + "Developer Infrastructure", + "DevEx" + ], + "language": "en", + "speakers": [ + "peter-garamvolgyi" + ], + "eventId": "devcon-7", + "slot_start": 1731581400000, + "slot_end": 1731582600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs" + }, + "vector": [ 0, 0, 0, @@ -471837,6 +472212,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -471945,7 +472321,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -472108,9 +472483,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -472123,45 +472496,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term", - "sourceId": "BF8EWR", - "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term", - "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "structures", - "processes" - ], - "tags": [ - "Coordination", - "DAO", - "Governance", - "processes", - "Coordination", - "DAO", - "Governance" - ], - "language": "en", - "speakers": [ - "krzysztof-urbanski" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU" - }, - "vector": [ 0, 0, 0, @@ -472173,7 +472507,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -472314,6 +472647,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -472604,7 +472938,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -472645,6 +472978,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -472668,6 +473002,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -472815,6 +473150,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -472997,12 +473333,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -473015,6 +473349,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -473056,7 +473391,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -473178,7 +473512,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -473190,8 +473526,46 @@ 0, 0, 0, - 2, 0, + 0 + ] + }, + { + "session": { + "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term", + "sourceId": "BF8EWR", + "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term", + "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "structures", + "processes" + ], + "tags": [ + "Coordination", + "DAO", + "Governance", + "processes", + "Coordination", + "DAO", + "Governance" + ], + "language": "en", + "speakers": [ + "krzysztof-urbanski" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU" + }, + "vector": [ 0, 0, 0, @@ -473203,6 +473577,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -473463,7 +473838,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -473472,7 +473846,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -473480,37 +473853,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l2-evm-common-core-a-path-beyond-evm-equivalence", - "sourceId": "9RJ3MA", - "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence", - "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "EVM-equivalent", - "Rollups" - ], - "language": "en", - "speakers": [ - "ansgar-dietrichs" - ], - "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731582600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk" - }, - "vector": [ 0, 0, 0, @@ -473518,7 +473860,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -473567,7 +473908,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -473670,6 +474010,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -474064,10 +474405,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -474121,6 +474464,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -474254,6 +474598,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -474292,7 +474637,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -474527,6 +474871,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -474535,6 +474880,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -474542,6 +474888,37 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "l2-evm-common-core-a-path-beyond-evm-equivalence", + "sourceId": "9RJ3MA", + "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence", + "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "EVM-equivalent", + "Rollups" + ], + "language": "en", + "speakers": [ + "ansgar-dietrichs" + ], + "eventId": "devcon-7", + "slot_start": 1731580800000, + "slot_end": 1731582600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk" + }, + "vector": [ 0, 0, 0, @@ -474549,6 +474926,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -474574,7 +474952,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -474599,6 +474976,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -474812,11 +475190,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -474829,44 +475205,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l2-interoperability-via-collaborative-snarks", - "sourceId": "JPGEPU", - "title": "L2 Interoperability via Collaborative SNARKs", - "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Interoperability" - ], - "tags": [ - "Fragmentation", - "Zk Rollups", - "Cryptography", - "interoperability", - "Cryptography", - "Fragmentation", - "Zk Rollups" - ], - "language": "en", - "speakers": [ - "ben-fisch" - ], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k" - }, - "vector": [ 0, 0, 0, @@ -474874,7 +475212,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -475310,7 +475647,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -475368,6 +475704,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -475619,7 +475957,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -475675,7 +476012,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -475888,9 +476224,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -475903,6 +476241,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "l2-interoperability-via-collaborative-snarks", + "sourceId": "JPGEPU", + "title": "L2 Interoperability via Collaborative SNARKs", + "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Interoperability" + ], + "tags": [ + "Fragmentation", + "Zk Rollups", + "Cryptography", + "interoperability", + "Cryptography", + "Fragmentation", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "ben-fisch" + ], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k" + }, + "vector": [ 0, 0, 0, @@ -475910,6 +476286,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -475998,7 +476375,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -476168,12 +476544,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -476185,44 +476559,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "l2-specific-mev-mitigation-strategies", - "sourceId": "FFWJAV", - "title": "L2 Specific MEV Mitigation Strategies", - "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "DeFi" - ], - "tags": [ - "Layer 2s", - "Rollups", - "MEV", - "defi", - "Layer 2s", - "MEV", - "Rollups" - ], - "language": "en", - "speakers": [ - "joseph-poon" - ], - "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY" - }, - "vector": [ 0, 0, 0, @@ -476230,7 +476566,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -476389,6 +476724,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -476667,7 +477003,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -476700,6 +477035,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -476729,6 +477065,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -476754,6 +477091,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -476964,7 +477302,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -477004,7 +477341,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -477028,7 +477364,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -477079,6 +477414,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -477155,7 +477491,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -477249,10 +477584,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -477264,6 +477601,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "l2-specific-mev-mitigation-strategies", + "sourceId": "FFWJAV", + "title": "L2 Specific MEV Mitigation Strategies", + "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "DeFi" + ], + "tags": [ + "Layer 2s", + "Rollups", + "MEV", + "defi", + "Layer 2s", + "MEV", + "Rollups" + ], + "language": "en", + "speakers": [ + "joseph-poon" + ], + "eventId": "devcon-7", + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY" + }, + "vector": [ 0, 0, 0, @@ -477271,6 +477646,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -477524,12 +477900,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -477541,53 +477915,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "latency-advantage-in-cex-dex-arbitrage", - "sourceId": "RPMHLF", - "title": "Latency Advantage in CEX-DEX Arbitrage", - "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Optimal", - "Stopping;", - "Dynamic", - "Programming;" - ], - "tags": [ - "Rollups", - "Economics", - "MEV", - "AMMs", - "programming", - "dynamic", - "AMMs", - "Economics", - "MEV", - "Rollups" - ], - "language": "en", - "speakers": [ - "akaki-mamageishvili" - ], - "eventId": "devcon-7", - "slot_start": 1731487200000, - "slot_end": 1731487800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -477756,6 +478085,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -478030,7 +478360,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -478055,6 +478384,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -478094,6 +478424,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -478117,6 +478448,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -478243,6 +478575,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -478326,7 +478665,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -478359,14 +478697,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -478407,7 +478743,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -478609,6 +478944,15 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -478617,8 +478961,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "latency-advantage-in-cex-dex-arbitrage", + "sourceId": "RPMHLF", + "title": "Latency Advantage in CEX-DEX Arbitrage", + "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Optimal", + "Stopping;", + "Dynamic", + "Programming;" + ], + "tags": [ + "Rollups", + "Economics", + "MEV", + "AMMs", + "programming", + "dynamic", + "AMMs", + "Economics", + "MEV", + "Rollups" + ], + "language": "en", + "speakers": [ + "akaki-mamageishvili" + ], + "eventId": "devcon-7", + "slot_start": 1731487200000, + "slot_end": 1731487800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -478726,8 +479115,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -478886,12 +479273,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -478903,57 +479288,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "launching-projects-out-of-the-global-majority", - "sourceId": "7VZ8WH", - "title": "Launching Projects out of the Global Majority", - "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Business", - "featured": false, - "doNotRecord": true, - "keywords": [ - "Global" - ], - "tags": [ - "DAO", - "Sufficient decentralization", - "Best Practices", - "macro/micro economics", - "global", - "Best Practices", - "DAO", - "macro/micro economics", - "Sufficient decentralization" - ], - "language": "en", - "speakers": [ - "james-waugh" - ], - "eventId": "devcon-7", - "slot_start": 1731478800000, - "slot_end": 1731479400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -479118,6 +479452,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -479389,7 +479724,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -479416,6 +479750,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -479448,12 +479783,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -479494,6 +479831,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -479713,7 +480051,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -479783,7 +480120,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -479814,6 +480150,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -479839,7 +480177,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -479897,8 +480234,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -479975,10 +480310,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -479990,12 +480327,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "launching-projects-out-of-the-global-majority", + "sourceId": "7VZ8WH", + "title": "Launching Projects out of the Global Majority", + "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Business", + "featured": false, + "doNotRecord": true, + "keywords": [ + "Global" + ], + "tags": [ + "DAO", + "Sufficient decentralization", + "Best Practices", + "macro/micro economics", + "global", + "Best Practices", + "DAO", + "macro/micro economics", + "Sufficient decentralization" + ], + "language": "en", + "speakers": [ + "james-waugh" + ], + "eventId": "devcon-7", + "slot_start": 1731478800000, + "slot_end": 1731479400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -480086,7 +480464,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -480244,14 +480621,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -480261,45 +480636,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto", - "sourceId": "HCXCXB", - "title": "Lazarus! How to stay safe from the biggest threat actor in crypto", - "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Lazarus" - ], - "tags": [ - "Security", - "Best Practices", - "Hacks", - "lazarus", - "Best Practices", - "Hacks", - "Security" - ], - "language": "en", - "speakers": [ - "mudit-gupta" - ], - "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk" - }, - "vector": [ - 6, 0, 0, 0, @@ -480479,6 +480815,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -480746,7 +481083,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -480805,6 +481141,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -480874,6 +481211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -480929,6 +481267,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -480986,6 +481325,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -481038,7 +481378,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -481069,7 +481408,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -481176,6 +481514,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -481290,7 +481629,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -481334,12 +481672,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -481349,6 +481689,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto", + "sourceId": "HCXCXB", + "title": "Lazarus! How to stay safe from the biggest threat actor in crypto", + "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Lazarus" + ], + "tags": [ + "Security", + "Best Practices", + "Hacks", + "lazarus", + "Best Practices", + "Hacks", + "Security" + ], + "language": "en", + "speakers": [ + "mudit-gupta" + ], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731582000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk" + }, + "vector": [ + 6, 0, 0, 0, @@ -481443,7 +481822,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -481600,11 +481978,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -481617,52 +481993,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "learn-huff-to-become-an-evm-chad", - "sourceId": "HRMCBK", - "title": "Learn Huff to become an EVM chad", - "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Developper", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Education", - "Huff", - "Programming" - ], - "tags": [ - "Tooling", - "Languages", - "Open Source Software", - "Best Practices", - "programming", - "Best Practices", - "Languages", - "Open Source Software", - "Tooling" - ], - "language": "en", - "speakers": [ - "clement-lakhal" - ], - "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731571200000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -481843,6 +482176,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -482107,7 +482441,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -482137,6 +482470,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -482167,6 +482501,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482387,6 +482722,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482419,7 +482755,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -482429,7 +482764,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -482495,8 +482829,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -482543,6 +482875,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -482699,9 +483032,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -482714,9 +483049,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "learn-huff-to-become-an-evm-chad", + "sourceId": "HRMCBK", + "title": "Learn Huff to become an EVM chad", + "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developper", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Education", + "Huff", + "Programming" + ], + "tags": [ + "Tooling", + "Languages", + "Open Source Software", + "Best Practices", + "programming", + "Best Practices", + "Languages", + "Open Source Software", + "Tooling" + ], + "language": "en", + "speakers": [ + "clement-lakhal" + ], + "eventId": "devcon-7", + "slot_start": 1731564000000, + "slot_end": 1731571200000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -482800,7 +483178,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -482960,7 +483337,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -482972,43 +483348,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "lessons-and-learning-in-people-ops-at-the-ef", - "sourceId": "D7V8ZY", - "title": "Lessons & Learning in People Ops at the EF", - "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "people", - "growth", - "open" - ], - "tags": [], - "language": "en", - "speakers": [ - "jose-pedro-cabrita" - ], - "eventId": "devcon-7", - "slot_start": 1731652800000, - "slot_end": 1731654000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c" - }, - "vector": [ 0, 0, 0, @@ -483020,7 +483363,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -483199,6 +483541,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -483458,7 +483801,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -483513,6 +483855,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -483522,6 +483865,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -483587,6 +483931,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -483890,6 +484236,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -484049,6 +484396,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -484060,10 +484408,43 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lessons-and-learning-in-people-ops-at-the-ef", + "sourceId": "D7V8ZY", + "title": "Lessons & Learning in People Ops at the EF", + "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "people", + "growth", + "open" + ], + "tags": [], + "language": "en", + "speakers": [ + "jose-pedro-cabrita" + ], + "eventId": "devcon-7", + "slot_start": 1731652800000, + "slot_end": 1731654000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c" + }, + "vector": [ 0, 0, 0, @@ -484075,6 +484456,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -484312,14 +484694,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -484327,43 +484707,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm", - "sourceId": "LL799L", - "title": "Lessons from integrating LogUp-GKR in the Miden VM", - "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "LogUp", - "GKR" - ], - "tags": [ - "Zero-Knowledge", - "Cryptography", - "gkr", - "Cryptography", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "philippe-laferriere" - ], - "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg" - }, - "vector": [ 0, 0, 0, @@ -484374,7 +484717,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -484554,6 +484896,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -484814,7 +485157,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -485115,8 +485457,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -485412,12 +485752,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -485425,6 +485767,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm", + "sourceId": "LL799L", + "title": "Lessons from integrating LogUp-GKR in the Miden VM", + "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "LogUp", + "GKR" + ], + "tags": [ + "Zero-Knowledge", + "Cryptography", + "gkr", + "Cryptography", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "philippe-laferriere" + ], + "eventId": "devcon-7", + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg" + }, + "vector": [ 0, 0, 0, @@ -485435,6 +485814,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -485509,7 +485889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -485668,8 +486047,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -485682,55 +486059,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia", - "sourceId": "F7Z87P", - "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia", - "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Local/SEA", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Ethereum", - "Use", - "Cases" - ], - "tags": [ - "Ethereum for Good", - "Climate", - "SEA", - "ethereum", - "case", - "use", - "Climate", - "Ethereum for Good", - "SEA" - ], - "language": "en", - "speakers": [ - "gesa-schneider" - ], - "eventId": "devcon-7", - "slot_start": 1731574200000, - "slot_end": 1731574800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -485922,6 +486256,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -486175,7 +486510,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -486225,6 +486559,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -486589,7 +486925,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486598,7 +486933,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486619,6 +486953,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -486709,7 +487044,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -486771,13 +487105,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 0, + 2, 2, 0, 0, @@ -486791,12 +487126,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia", + "sourceId": "F7Z87P", + "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia", + "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Local/SEA", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Ethereum", + "Use", + "Cases" + ], + "tags": [ + "Ethereum for Good", + "Climate", + "SEA", + "ethereum", + "case", + "use", + "Climate", + "Ethereum for Good", + "SEA" + ], + "language": "en", + "speakers": [ + "gesa-schneider" + ], + "eventId": "devcon-7", + "slot_start": 1731574200000, + "slot_end": 1731574800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -487027,7 +487405,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -487041,47 +487418,6 @@ 0, 0, 0, - 2, - 0 - ] - }, - { - "session": { - "id": "leveraging-high-performance-computing-for-efficient-stark-provers", - "sourceId": "ZGXYDF", - "title": "Leveraging High-Performance Computing for Efficient STARK Provers", - "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "computing performance", - "optimization", - "" - ], - "tags": [ - "ZK-EVMs", - "ZKP", - "STARK", - "optimization", - "STARK", - "ZK-EVMs", - "ZKP" - ], - "language": "en", - "speakers": [ - "ricard-borrell" - ], - "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731479400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0" - }, - "vector": [ 0, 0, 0, @@ -487092,7 +487428,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -487286,6 +487621,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -487534,7 +487872,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -487700,6 +488037,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -487707,6 +488046,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -487817,6 +488157,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -487878,6 +488219,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 0, 0, 0, @@ -487896,7 +488247,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -488034,7 +488384,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -488126,12 +488475,61 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, + 2, + 0 + ] + }, + { + "session": { + "id": "leveraging-high-performance-computing-for-efficient-stark-provers", + "sourceId": "ZGXYDF", + "title": "Leveraging High-Performance Computing for Efficient STARK Provers", + "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "computing performance", + "optimization", + "" + ], + "tags": [ + "ZK-EVMs", + "ZKP", + "STARK", + "optimization", + "STARK", + "ZK-EVMs", + "ZKP" + ], + "language": "en", + "speakers": [ + "ricard-borrell" + ], + "eventId": "devcon-7", + "slot_start": 1731477600000, + "slot_end": 1731479400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0" + }, + "vector": [ 0, 0, 0, @@ -488142,6 +488540,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -488169,8 +488568,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -488383,11 +488780,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -488400,41 +488795,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "light-client-support-in-prysm", - "sourceId": "9PC3EY", - "title": "Light Client Support in Prysm", - "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Prysm" - ], - "tags": [ - "EPF", - "Consensus", - "Light Clients" - ], - "language": "en", - "speakers": [ - "bastin", - "rupam" - ], - "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731476700000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q" - }, - "vector": [ 0, 0, 0, @@ -488450,7 +488810,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -488625,6 +488984,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -488888,8 +489248,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -488990,6 +489348,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -489127,6 +489486,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -489179,7 +489539,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -489194,7 +489553,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -489263,6 +489621,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -489475,6 +489835,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -489482,6 +489843,50 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "light-client-support-in-prysm", + "sourceId": "9PC3EY", + "title": "Light Client Support in Prysm", + "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Prysm" + ], + "tags": [ + "EPF", + "Consensus", + "Light Clients" + ], + "language": "en", + "speakers": [ + "bastin", + "rupam" + ], + "eventId": "devcon-7", + "slot_start": 1731475800000, + "slot_end": 1731476700000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q" + }, + "vector": [ 0, 0, 0, @@ -489497,6 +489902,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -489736,11 +490142,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -489753,54 +490157,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "lighthouse-introduction-to-siren", - "sourceId": "F3ZPRJ", - "title": "Lighthouse: Introduction to Siren", - "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "tags": [ - "Home staking", - "UI/UX", - "Accessibility", - "ui", - "Accessibility", - "Home staking", - "UI/UX" - ], - "keywords": [ - "lighthouse", - "UI" - ], - "duration": 388, - "language": "en", - "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4", - "sources_youtubeId": "RhlKmJqk0go", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt", - "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.", - "eventId": "devcon-7", - "slot_start": 1731408000000, - "slot_end": 1731408600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w", - "resources_slides": null, - "speakers": [ - "ricki-moore" - ] - }, - "vector": [ 0, 0, 0, @@ -489809,7 +490165,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -489987,6 +490342,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -490256,7 +490613,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -490279,6 +490635,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -490293,6 +490650,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -490576,6 +490934,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -490599,8 +490958,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -490626,7 +490983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -490836,9 +491192,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -490851,6 +491209,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lighthouse-introduction-to-siren", + "sourceId": "F3ZPRJ", + "title": "Lighthouse: Introduction to Siren", + "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "tags": [ + "Home staking", + "UI/UX", + "Accessibility", + "ui", + "Accessibility", + "Home staking", + "UI/UX" + ], + "keywords": [ + "lighthouse", + "UI" + ], + "duration": 388, + "language": "en", + "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4", + "sources_youtubeId": "RhlKmJqk0go", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt", + "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.", + "eventId": "devcon-7", + "slot_start": 1731408000000, + "slot_end": 1731408600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w", + "resources_slides": null, + "speakers": [ + "ricki-moore" + ] + }, + "vector": [ 0, 0, 0, @@ -490859,6 +491265,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -490947,7 +491354,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -491104,56 +491510,7 @@ 0, 0, 0, - 2, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "lighthouse-transition-journey-from-warp-to-axum", - "sourceId": "ZF79GZ", - "title": "Lighthouse transition journey : from warp to axum", - "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Performance", - "Developer", - "experience" - ], - "tags": [ - "Developer Infrastructure", - "Light Clients" - ], - "language": "en", - "speakers": [ - "lea-narzis" - ], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731474900000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM" - }, - "vector": [ 0, 0, 0, @@ -491169,7 +491526,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -491358,6 +491714,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -491610,7 +491967,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -491703,6 +492059,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -491728,6 +492086,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -491913,7 +492272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -491947,7 +492305,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -492050,6 +492407,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -492206,6 +492564,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -492213,12 +492572,48 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lighthouse-transition-journey-from-warp-to-axum", + "sourceId": "ZF79GZ", + "title": "Lighthouse transition journey : from warp to axum", + "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Performance", + "Developer", + "experience" + ], + "tags": [ + "Developer Infrastructure", + "Light Clients" + ], + "language": "en", + "speakers": [ + "lea-narzis" + ], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731474900000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM" + }, + "vector": [ 0, 0, 0, @@ -492234,6 +492629,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -492455,11 +492851,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -492472,44 +492866,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "liquid-staking-for-daos", - "sourceId": "ZV39SQ", - "title": "Liquid Staking for DAOs", - "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "DAOs" - ], - "tags": [ - "Coordination", - "DAO", - "Best Practices", - "Mechanism design", - "Best Practices", - "Coordination", - "Mechanism design" - ], - "language": "en", - "speakers": [ - "dennison-bertram" - ], - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731396600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww" - }, - "vector": [ 0, 0, 0, @@ -492521,7 +492877,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -492717,6 +493072,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -492967,7 +493323,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -493022,6 +493377,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -493055,6 +493411,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -493256,7 +493613,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -493280,7 +493636,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -493350,7 +493705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -493404,7 +493758,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -493566,9 +493919,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -493581,6 +493936,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "liquid-staking-for-daos", + "sourceId": "ZV39SQ", + "title": "Liquid Staking for DAOs", + "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "DAOs" + ], + "tags": [ + "Coordination", + "DAO", + "Best Practices", + "Mechanism design", + "Best Practices", + "Coordination", + "Mechanism design" + ], + "language": "en", + "speakers": [ + "dennison-bertram" + ], + "eventId": "devcon-7", + "slot_start": 1731394800000, + "slot_end": 1731396600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww" + }, + "vector": [ 0, 0, 0, @@ -493592,6 +493985,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -493813,14 +494207,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -493828,32 +494220,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "liron-achdut", - "sourceId": "TPPWYB", - "title": "Liron Achdut", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731657600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo" - }, - "vector": [ 0, 0, 0, @@ -493863,7 +494229,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -494068,6 +494433,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -494358,6 +494724,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -494381,6 +494748,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -494450,6 +494818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -494503,6 +494872,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -494911,12 +495281,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -494924,6 +495296,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "liron-achdut", + "sourceId": "TPPWYB", + "title": "Liron Achdut", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731654000000, + "slot_end": 1731657600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo" + }, + "vector": [ 0, 0, 0, @@ -494933,6 +495331,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -495156,10 +495555,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -495172,42 +495569,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "little-things-weve-learned-about-fhe", - "sourceId": "9JFDZA", - "title": "Little Things We've learned About FHE", - "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ELI5" - ], - "tags": [ - "Cryptography", - "Homomorphic Encryption", - "eli5", - "Cryptography", - "Homomorphic Encryption" - ], - "language": "en", - "speakers": [ - "chih-cheng-liang" - ], - "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k" - }, - "vector": [ 0, 0, 0, @@ -495218,7 +495579,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -495666,7 +496026,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -495960,7 +496319,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -496037,7 +496395,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -496271,8 +496628,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -496285,6 +496644,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "little-things-weve-learned-about-fhe", + "sourceId": "9JFDZA", + "title": "Little Things We've learned About FHE", + "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ELI5" + ], + "tags": [ + "Cryptography", + "Homomorphic Encryption", + "eli5", + "Cryptography", + "Homomorphic Encryption" + ], + "language": "en", + "speakers": [ + "chih-cheng-liang" + ], + "eventId": "devcon-7", + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k" + }, + "vector": [ 0, 0, 0, @@ -496295,6 +496690,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -496355,7 +496752,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -496509,11 +496905,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -496526,34 +496920,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "live-music-open-jam-or-something-in-between", - "sourceId": "FVHR9Y", - "title": "Live Music, Open Jam, Or Something In Between", - "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.", - "track": "Entertainment", - "type": "Music", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "marc-nitzsche" - ], - "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731481200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4" - }, - "vector": [ 0, 0, 0, @@ -496563,7 +496929,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -496775,6 +497140,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -497013,7 +497381,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -497069,6 +497436,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -497144,6 +497513,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -497460,6 +497831,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -497613,9 +497985,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -497628,6 +498002,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "live-music-open-jam-or-something-in-between", + "sourceId": "FVHR9Y", + "title": "Live Music, Open Jam, Or Something In Between", + "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.", + "track": "Entertainment", + "type": "Music", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "marc-nitzsche" + ], + "eventId": "devcon-7", + "slot_start": 1731477600000, + "slot_end": 1731481200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4" + }, + "vector": [ 0, 0, 0, @@ -497637,6 +498039,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -497855,7 +498258,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -497864,64 +498266,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "liveops-for-autonomous-worlds", - "sourceId": "DGU8PN", - "title": "Liveops for autonomous worlds", - "description": "How do you keep a world alive, especially one that is deliberately ownerless and autonomous?\r\n\r\nAs creators and stewards of a world, how should you react and not react to certain events unfolding in the world? \r\n\r\nWe will share our experience and learnings from running This Cursed Machine and previous projects.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "arthur-roing-baer", - "alex-declino", - "rasmus-svensson" - ], - "eventId": "devcon-7", - "slot_start": 1731579300000, - "slot_end": 1731580800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, 0, 0, 0, @@ -498147,6 +498491,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -498367,9 +498712,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -498756,9 +499098,6 @@ 0, 0, 0, - 2, - 2, - 0, 0, 0, 0, @@ -498996,6 +499335,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -499004,6 +499344,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -499011,6 +499352,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "liveops-for-autonomous-worlds", + "sourceId": "DGU8PN", + "title": "Liveops for autonomous worlds", + "description": "How do you keep a world alive, especially one that is deliberately ownerless and autonomous?\r\n\r\nAs creators and stewards of a world, how should you react and not react to certain events unfolding in the world? \r\n\r\nWe will share our experience and learnings from running This Cursed Machine and previous projects.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "arthur-roing-baer", + "alex-declino", + "rasmus-svensson" + ], + "eventId": "devcon-7", + "slot_start": 1731579300000, + "slot_end": 1731580800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk" + }, + "vector": [ 0, 0, 0, @@ -499023,6 +499399,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -499210,13 +499587,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -499225,47 +499600,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "local-build-why-language-is-key-to-decentralization", - "sourceId": "UHVBNL", - "title": "Local Build: Why language is key to decentralization", - "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Internationalization", - "Localization" - ], - "tags": [ - "Decentralization Improvements", - "Languages", - "User Experience", - "localization", - "l10n", - "Decentralization Improvements", - "Languages", - "User Experience" - ], - "language": "en", - "speakers": [ - "oliver-jl-renwick", - "laurel" - ], - "eventId": "devcon-7", - "slot_start": 1731490800000, - "slot_end": 1731491400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0" - }, - "vector": [ 0, 0, 0, @@ -499277,7 +499611,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -499516,6 +499849,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -499729,8 +500065,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -499906,6 +500240,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -500011,7 +500347,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -500021,7 +500356,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -500102,7 +500436,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -500361,11 +500694,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -500374,6 +500709,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "local-build-why-language-is-key-to-decentralization", + "sourceId": "UHVBNL", + "title": "Local Build: Why language is key to decentralization", + "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Internationalization", + "Localization" + ], + "tags": [ + "Decentralization Improvements", + "Languages", + "User Experience", + "localization", + "l10n", + "Decentralization Improvements", + "Languages", + "User Experience" + ], + "language": "en", + "speakers": [ + "oliver-jl-renwick", + "laurel" + ], + "eventId": "devcon-7", + "slot_start": 1731490800000, + "slot_end": 1731491400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0" + }, + "vector": [ 0, 0, 0, @@ -500385,6 +500761,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -500414,8 +500791,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -500567,7 +500942,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -500575,7 +500949,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -500584,52 +500957,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "logs-for-you-anon", - "sourceId": "RRYVNW", - "title": "Logs for you anon", - "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "logs", - "local apps", - "indexing" - ], - "tags": [ - "DevEx", - "Privacy", - "Decentralization", - "indexing", - "Decentralization", - "DevEx", - "Privacy" - ], - "language": "en", - "speakers": [ - "yabir-garcia-benchakhtir" - ], - "eventId": "devcon-7", - "slot_start": 1731646200000, - "slot_end": 1731646800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -500883,6 +501215,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -501089,7 +501423,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -501166,6 +501499,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -501175,6 +501509,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -501255,6 +501590,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -501393,7 +501729,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501465,7 +501800,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501480,7 +501814,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501569,6 +501902,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -501720,6 +502055,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -501727,6 +502063,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -501735,11 +502072,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "logs-for-you-anon", + "sourceId": "RRYVNW", + "title": "Logs for you anon", + "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "logs", + "local apps", + "indexing" + ], + "tags": [ + "DevEx", + "Privacy", + "Decentralization", + "indexing", + "Decentralization", + "DevEx", + "Privacy" + ], + "language": "en", + "speakers": [ + "yabir-garcia-benchakhtir" + ], + "eventId": "devcon-7", + "slot_start": 1731646200000, + "slot_end": 1731646800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -501774,7 +502152,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -501925,11 +502302,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -501942,49 +502317,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "long-term-decentralized-storage-for-blobs", - "sourceId": "RCVFHX", - "title": "Long-term Decentralized Storage for Blobs", - "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Storage" - ], - "tags": [ - "Core Protocol", - "Blobs", - "Sustainability", - "storage", - "Blobs", - "Core Protocol", - "Sustainability" - ], - "language": "en", - "speakers": [ - "leo-bautista-gomez" - ], - "eventId": "devcon-7", - "slot_start": 1731469800000, - "slot_end": 1731470400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -502243,6 +502579,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -502446,7 +502785,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -502547,6 +502885,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -502618,6 +502957,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -502632,6 +502972,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -502738,7 +503082,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -502783,7 +503126,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -502924,6 +503266,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -503067,6 +503417,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 2, @@ -503082,6 +503434,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "long-term-decentralized-storage-for-blobs", + "sourceId": "RCVFHX", + "title": "Long-term Decentralized Storage for Blobs", + "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Storage" + ], + "tags": [ + "Core Protocol", + "Blobs", + "Sustainability", + "storage", + "Blobs", + "Core Protocol", + "Sustainability" + ], + "language": "en", + "speakers": [ + "leo-bautista-gomez" + ], + "eventId": "devcon-7", + "slot_start": 1731469800000, + "slot_end": 1731470400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -503131,7 +503534,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -503281,7 +503683,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -503289,7 +503690,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -503298,50 +503698,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "lunarpunk-endgame", - "sourceId": "EVHFWA", - "title": "Lunarpunk Endgame", - "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Lunarpunk" - ], - "tags": [ - "Network State", - "Anonymity", - "Autonomous World", - "lunarpunk", - "Anonymity", - "Autonomous World", - "Network State" - ], - "language": "en", - "speakers": [ - "rachel-rose-oleary" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -503579,6 +503940,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -503803,7 +504165,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -503873,6 +504234,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -503917,6 +504279,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -504101,7 +504467,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504122,7 +504487,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504185,7 +504549,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504202,6 +504565,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -504260,6 +504627,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -504408,6 +504777,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -504415,6 +504785,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -504423,11 +504794,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "lunarpunk-endgame", + "sourceId": "EVHFWA", + "title": "Lunarpunk Endgame", + "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.", + "track": "Cypherpunk & Privacy", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Lunarpunk" + ], + "tags": [ + "Network State", + "Anonymity", + "Autonomous World", + "lunarpunk", + "Anonymity", + "Autonomous World", + "Network State" + ], + "language": "en", + "speakers": [ + "rachel-rose-oleary" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -504488,7 +504898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -504639,9 +505048,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -504654,54 +505061,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to", - "sourceId": "TCJJW3", - "title": "MACI - Why do we need private voting and what are we up to", - "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Coordination", - "Quadratic Voting", - "Public good", - "voting", - "Coordination", - "Public good", - "Quadratic Voting" - ], - "keywords": [ - "Privacy", - "Voting" - ], - "duration": 606, - "language": "en", - "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6", - "sources_youtubeId": "18KFAia72Ww", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt", - "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.", - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731395400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg", - "resources_slides": null, - "speakers": [ - "ctrlc03" - ] - }, - "vector": [ 0, 0, 0, @@ -504712,7 +505071,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -504943,6 +505301,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -505170,7 +505529,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -505243,6 +505601,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505263,6 +505622,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505325,6 +505685,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505550,7 +505911,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -505596,7 +505956,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -505629,6 +505988,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -505652,7 +506012,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -505780,7 +506139,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -505793,6 +506154,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to", + "sourceId": "TCJJW3", + "title": "MACI - Why do we need private voting and what are we up to", + "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Coordination", + "Quadratic Voting", + "Public good", + "voting", + "Coordination", + "Public good", + "Quadratic Voting" + ], + "keywords": [ + "Privacy", + "Voting" + ], + "duration": 606, + "language": "en", + "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6", + "sources_youtubeId": "18KFAia72Ww", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt", + "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.", + "eventId": "devcon-7", + "slot_start": 1731394800000, + "slot_end": 1731395400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg", + "resources_slides": null, + "speakers": [ + "ctrlc03" + ] + }, + "vector": [ 0, 0, 0, @@ -505802,8 +506211,8 @@ 0, 0, 0, - 2, 0, + 6, 0, 0, 0, @@ -506003,11 +506412,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -506020,62 +506427,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses", - "sourceId": "RGMXQ7", - "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses", - "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "d/acc", - "adoption", - "messaging" - ], - "tags": [ - "Frameworks", - "Values", - "Use cases of cryptography", - "messaging", - "Frameworks", - "Use cases of cryptography", - "Values" - ], - "language": "en", - "speakers": [ - "vivek-bhupatiraju" - ], - "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731496200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -506321,6 +506672,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -506328,7 +506680,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -506703,6 +507054,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -506748,6 +507100,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -506803,6 +507156,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -506827,7 +507181,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -506904,14 +507257,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -506955,6 +507306,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -507155,9 +507507,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -507170,11 +507524,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses", + "sourceId": "RGMXQ7", + "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses", + "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "d/acc", + "adoption", + "messaging" + ], + "tags": [ + "Frameworks", + "Values", + "Use cases of cryptography", + "messaging", + "Frameworks", + "Use cases of cryptography", + "Values" + ], + "language": "en", + "speakers": [ + "vivek-bhupatiraju" + ], + "eventId": "devcon-7", + "slot_start": 1731495600000, + "slot_end": 1731496200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -507213,7 +507608,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -507363,13 +507757,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -507378,32 +507770,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "manu-alzuru", - "sourceId": "GNMHSF", - "title": "Manu Alzuru", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731657600000, - "slot_end": 1731661200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM" - }, - "vector": [ 0, 0, 0, @@ -507413,7 +507779,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -507468,6 +507833,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -507969,6 +508335,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -508045,12 +508412,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -508352,6 +508721,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -508501,11 +508871,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -508514,6 +508886,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "manu-alzuru", + "sourceId": "GNMHSF", + "title": "Manu Alzuru", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731657600000, + "slot_end": 1731661200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM" + }, + "vector": [ 0, 0, 0, @@ -508523,6 +508921,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -508706,10 +509105,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -508722,53 +509119,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "maximum-viable-security-mvs-a-new-issuance-framework", - "sourceId": "KWUF3N", - "title": "Maximum Viable Security (MVS) – a new issuance framework", - "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "neutrality", - "autonomy", - "validator set composition" - ], - "tags": [ - "Staking", - "Validator Experience", - "Security", - "composability", - "validator", - "set", - "Security", - "Staking", - "Validator Experience" - ], - "language": "en", - "speakers": [ - "artem-kotelskiy" - ], - "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -509233,7 +509587,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -509503,7 +509856,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -509541,7 +509893,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -509632,7 +509983,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -509868,8 +510218,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -509882,10 +510234,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "maximum-viable-security-mvs-a-new-issuance-framework", + "sourceId": "KWUF3N", + "title": "Maximum Viable Security (MVS) – a new issuance framework", + "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "neutrality", + "autonomy", + "validator set composition" + ], + "tags": [ + "Staking", + "Validator Experience", + "Security", + "composability", + "validator", + "set", + "Security", + "Staking", + "Validator Experience" + ], + "language": "en", + "speakers": [ + "artem-kotelskiy" + ], + "eventId": "devcon-7", + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo" + }, + "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -509918,9 +510314,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -510065,12 +510458,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -510082,45 +510473,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "memecraft-effectively-communicating-crypto-concepts", - "sourceId": "FAKRPS", - "title": "Memecraft: Effectively Communicating Crypto Concepts", - "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "memes" - ], - "tags": [ - "Public good", - "Marketing", - "User Research", - "memes", - "Marketing", - "Public good", - "User Research" - ], - "language": "en", - "speakers": [ - "joshua-davila", - "beth-mccarthy" - ], - "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731643800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I" - }, - "vector": [ 0, 0, 0, @@ -510132,7 +510484,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -510396,6 +510747,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -510591,8 +510943,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -510669,6 +511019,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -510706,6 +511057,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -510796,6 +511148,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -510947,7 +511300,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -510969,7 +511321,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511083,6 +511434,21 @@ 0, 0, 0, + 2, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -511150,7 +511516,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511216,6 +511581,62 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "memecraft-effectively-communicating-crypto-concepts", + "sourceId": "FAKRPS", + "title": "Memecraft: Effectively Communicating Crypto Concepts", + "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "memes" + ], + "tags": [ + "Public good", + "Marketing", + "User Research", + "memes", + "Marketing", + "Public good", + "User Research" + ], + "language": "en", + "speakers": [ + "joshua-davila", + "beth-mccarthy" + ], + "eventId": "devcon-7", + "slot_start": 1731642000000, + "slot_end": 1731643800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I" + }, + "vector": [ 0, 0, 0, @@ -511227,6 +511648,13 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -511278,7 +511706,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511422,7 +511849,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511431,7 +511857,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -511439,43 +511864,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "merkle-proofs-when-leaves-leave-you-vulnerable", - "sourceId": "LAKCG3", - "title": "Merkle Proofs: When Leaves Leave You Vulnerable", - "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Merkle" - ], - "tags": [ - "Auditing", - "Bug", - "merkle", - "Auditing", - "Bug" - ], - "language": "en", - "speakers": [ - "shufan-wang" - ], - "eventId": "devcon-7", - "slot_start": 1731390000000, - "slot_end": 1731390600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c" - }, - "vector": [ - 6, 0, 0, 0, @@ -511721,6 +512109,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -511947,7 +512337,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -512078,6 +512467,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512099,6 +512489,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512279,6 +512670,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512366,7 +512758,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -512407,6 +512798,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512489,7 +512881,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -512551,6 +512942,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512559,6 +512951,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -512566,6 +512959,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "merkle-proofs-when-leaves-leave-you-vulnerable", + "sourceId": "LAKCG3", + "title": "Merkle Proofs: When Leaves Leave You Vulnerable", + "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Merkle" + ], + "tags": [ + "Auditing", + "Bug", + "merkle", + "Auditing", + "Bug" + ], + "language": "en", + "speakers": [ + "shufan-wang" + ], + "eventId": "devcon-7", + "slot_start": 1731390000000, + "slot_end": 1731390600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c" + }, + "vector": [ + 6, 0, 0, 0, @@ -512633,7 +513063,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -512776,11 +513205,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -512793,53 +513220,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "modern-zkp-compilers", - "sourceId": "CV7QXP", - "title": "Modern ZKP compilers", - "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Developer Infrastructure", - "Languages", - "ZKP", - "education", - "Developer Infrastructure", - "Languages", - "ZKP" - ], - "keywords": [ - "education" - ], - "duration": 645, - "language": "en", - "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c", - "sources_youtubeId": "JX9YtcG_EHk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt", - "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.", - "eventId": "devcon-7", - "slot_start": 1731393000000, - "slot_end": 1731393600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ", - "resources_slides": null, - "speakers": [ - "leo-lara" - ] - }, - "vector": [ 0, 0, 0, @@ -512850,7 +513230,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -513090,6 +513469,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -513313,7 +513693,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -513511,6 +513890,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -513654,9 +514034,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -513670,18 +514047,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -513792,6 +514157,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -513934,9 +514300,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -513949,6 +514317,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "modern-zkp-compilers", + "sourceId": "CV7QXP", + "title": "Modern ZKP compilers", + "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Developer Infrastructure", + "Languages", + "ZKP", + "education", + "Developer Infrastructure", + "Languages", + "ZKP" + ], + "keywords": [ + "education" + ], + "duration": 645, + "language": "en", + "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c", + "sources_youtubeId": "JX9YtcG_EHk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt", + "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.", + "eventId": "devcon-7", + "slot_start": 1731393000000, + "slot_end": 1731393600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ", + "resources_slides": null, + "speakers": [ + "leo-lara" + ] + }, + "vector": [ 0, 0, 0, @@ -513959,6 +514374,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -514141,11 +514557,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -514158,48 +514572,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "molecular-verification-tools-to-enhance-public-trust-during-pandemic-response", - "sourceId": "BRUGUL", - "title": "Molecular verification tools to enhance public trust during pandemic response", - "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Molecular", - "Biology.", - "", - "Public", - "Health.", - "", - "Public", - "Trust." - ], - "tags": [ - "Decentralization", - "Public good" - ], - "language": "en", - "speakers": [ - "phillip-j-buckhaults" - ], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731571800000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -514466,6 +514839,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -514672,7 +515046,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -514788,6 +515161,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -514808,6 +515182,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -514823,11 +515198,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -515039,46 +515416,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -515332,9 +515669,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -515347,7 +515686,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "molecular-verification-tools-to-enhance-public-trust-during-pandemic-response", + "sourceId": "BRUGUL", + "title": "Molecular verification tools to enhance public trust during pandemic response", + "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Molecular", + "Biology.", + "", + "Public", + "Health.", + "", + "Public", + "Trust." + ], + "tags": [ + "Decentralization", + "Public good" + ], + "language": "en", + "speakers": [ + "phillip-j-buckhaults" + ], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731571800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -515499,12 +515879,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -515516,32 +515894,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mood-rebalancing-singing-bowls-handpan", - "sourceId": "SVAHJU", - "title": "Mood Rebalancing (Singing Bowls + Handpan)", - "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731644100000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw" - }, - "vector": [ 0, 0, 0, @@ -515551,7 +515903,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -515851,6 +516202,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -516219,12 +516571,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -516677,10 +517031,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -516692,6 +517048,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mood-rebalancing-singing-bowls-handpan", + "sourceId": "SVAHJU", + "title": "Mood Rebalancing (Singing Bowls + Handpan)", + "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731644100000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw" + }, + "vector": [ 0, 0, 0, @@ -516701,6 +517083,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -516844,10 +517227,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -516860,32 +517241,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mood-uplifting-singing-bowls-handpan", - "sourceId": "H7Y7L8", - "title": "Mood Uplifting (Singing Bowls + Handpan)", - "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731573900000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw" - }, - "vector": [ 0, 0, 0, @@ -516895,7 +517250,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -518026,8 +518380,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -518040,6 +518396,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mood-uplifting-singing-bowls-handpan", + "sourceId": "H7Y7L8", + "title": "Mood Uplifting (Singing Bowls + Handpan)", + "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731573900000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw" + }, + "vector": [ 0, 0, 0, @@ -518049,6 +518431,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -518188,10 +518571,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -518204,55 +518585,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mopro-make-client-side-proving-on-mobile-easy", - "sourceId": "BZWFEM", - "title": "Mopro: Make Client-side Proving on Mobile Easy", - "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "tags": [ - "ZKP", - "Cryptography", - "Mobile", - "android", - "Cryptography", - "Mobile", - "ZKP" - ], - "keywords": [ - "iOS", - "Android" - ], - "duration": 958, - "language": "en", - "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649", - "sources_youtubeId": "0ziKiYwhJHk", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt", - "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you", - "eventId": "devcon-7", - "slot_start": 1731397800000, - "slot_end": 1731398400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk", - "resources_slides": null, - "speakers": [ - "ya-wen-jeng", - "moven-tsai" - ] - }, - "vector": [ 0, 0, 0, @@ -518263,7 +518595,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -518728,8 +519059,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -519005,7 +519334,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -519015,7 +519343,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -519067,7 +519394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -519354,7 +519680,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -519403,8 +519728,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -519417,6 +519744,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mopro-make-client-side-proving-on-mobile-easy", + "sourceId": "BZWFEM", + "title": "Mopro: Make Client-side Proving on Mobile Easy", + "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "tags": [ + "ZKP", + "Cryptography", + "Mobile", + "android", + "Cryptography", + "Mobile", + "ZKP" + ], + "keywords": [ + "iOS", + "Android" + ], + "duration": 958, + "language": "en", + "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649", + "sources_youtubeId": "0ziKiYwhJHk", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt", + "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you", + "eventId": "devcon-7", + "slot_start": 1731397800000, + "slot_end": 1731398400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk", + "resources_slides": null, + "speakers": [ + "ya-wen-jeng", + "moven-tsai" + ] + }, + "vector": [ 0, 0, 0, @@ -519427,6 +519803,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -519554,13 +519931,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -519571,44 +519946,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on", - "sourceId": "9JYWVP", - "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.", - "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "FHE", - "MPC", - "Explorations" - ], - "tags": [ - "Homomorphic Encryption", - "Use cases of cryptography", - "exploration", - "Homomorphic Encryption", - "Use cases of cryptography" - ], - "language": "en", - "speakers": [ - "cperezz" - ], - "eventId": "devcon-7", - "slot_start": 1731391800000, - "slot_end": 1731392400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY" - }, - "vector": [ 0, 0, 0, @@ -519619,7 +519956,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -519934,6 +520270,9 @@ 0, 0, 0, + 6, + 6, + 0, 0, 0, 0, @@ -520086,7 +520425,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -520211,6 +520549,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -520220,6 +520559,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -520271,6 +520611,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -520376,7 +520720,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -520438,7 +520781,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -520556,6 +520898,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -520755,11 +521098,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -520768,7 +521113,46 @@ 0, 0, 0, - 2, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on", + "sourceId": "9JYWVP", + "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.", + "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "FHE", + "MPC", + "Explorations" + ], + "tags": [ + "Homomorphic Encryption", + "Use cases of cryptography", + "exploration", + "Homomorphic Encryption", + "Use cases of cryptography" + ], + "language": "en", + "speakers": [ + "cperezz" + ], + "eventId": "devcon-7", + "slot_start": 1731391800000, + "slot_end": 1731392400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY" + }, + "vector": [ 0, 0, 0, @@ -520779,6 +521163,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -520910,11 +521295,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -520927,53 +521310,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mpc-tooling-or-how-to-create-mpc-apps", - "sourceId": "QLMYBD", - "title": "MPC Tooling or How to create MPC apps", - "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Tooling", - "Cryptography", - "MPC", - "Cryptography", - "MPC", - "Tooling" - ], - "keywords": [ - "Circom-MPC", - "MPC tooling" - ], - "duration": 489, - "language": "en", - "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa", - "sources_youtubeId": "eKpcf1JMNak", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt", - "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume", - "eventId": "devcon-7", - "slot_start": 1731390600000, - "slot_end": 1731391200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE", - "resources_slides": null, - "speakers": [ - "rasul-ibragimov" - ] - }, - "vector": [ 0, 0, 0, @@ -520984,7 +521320,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -521297,6 +521632,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -521452,7 +521788,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -521589,6 +521924,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -521650,6 +521986,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -521726,7 +522063,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -521734,7 +522070,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -521802,7 +522137,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -521982,6 +522316,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -522123,9 +522458,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -522138,6 +522475,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mpc-tooling-or-how-to-create-mpc-apps", + "sourceId": "QLMYBD", + "title": "MPC Tooling or How to create MPC apps", + "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Tooling", + "Cryptography", + "MPC", + "Cryptography", + "MPC", + "Tooling" + ], + "keywords": [ + "Circom-MPC", + "MPC tooling" + ], + "duration": 489, + "language": "en", + "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa", + "sources_youtubeId": "eKpcf1JMNak", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt", + "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume", + "eventId": "devcon-7", + "slot_start": 1731390600000, + "slot_end": 1731391200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE", + "resources_slides": null, + "speakers": [ + "rasul-ibragimov" + ] + }, + "vector": [ 0, 0, 0, @@ -522148,6 +522532,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -522275,11 +522660,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -522292,42 +522675,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mpc101-what-is-multi-party-computation", - "sourceId": "UTYK7X", - "title": "MPC101: What is Multi-party Computation?", - "description": "This workshop provides an in-depth introduction to Multiparty Computation (MPC), focusing on its principles, protocols, and practical applications. Participants will learn how to design and implement MPC solutions, enabling secure collaborative computing without compromising data privacy.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "MPC101" - ], - "tags": [ - "Privacy", - "MPC", - "mpc101", - "MPC", - "Privacy" - ], - "language": "en", - "speakers": [ - "vanishree-rao" - ], - "eventId": "devcon-7", - "slot_start": 1731655800000, - "slot_end": 1731656400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1_q4yi8p91iDLVndotuvo2cF9YthOVkTSawv6R3pIaKY" - }, - "vector": [ 0, 0, 0, @@ -522338,7 +522685,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -522656,6 +523002,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -522807,7 +523154,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -522932,6 +523278,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -522939,6 +523286,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -523006,6 +523354,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -523156,7 +523505,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -523184,7 +523532,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -523480,15 +523827,16 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -523496,6 +523844,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mpc101-what-is-multi-party-computation", + "sourceId": "UTYK7X", + "title": "MPC101: What is Multi-party Computation?", + "description": "This workshop provides an in-depth introduction to Multiparty Computation (MPC), focusing on its principles, protocols, and practical applications. Participants will learn how to design and implement MPC solutions, enabling secure collaborative computing without compromising data privacy.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "MPC101" + ], + "tags": [ + "Privacy", + "MPC", + "mpc101", + "MPC", + "Privacy" + ], + "language": "en", + "speakers": [ + "vanishree-rao" + ], + "eventId": "devcon-7", + "slot_start": 1731655800000, + "slot_end": 1731656400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1_q4yi8p91iDLVndotuvo2cF9YthOVkTSawv6R3pIaKY" + }, + "vector": [ 0, 0, 0, @@ -523506,6 +523890,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -523632,9 +524018,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -523646,61 +524030,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mpcstats", - "sourceId": "ND3S9R", - "title": "MPCStats", - "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Tooling", - "Privacy", - "MPC", - "Public good", - "verification", - "computation", - "MPC", - "Privacy", - "Public good", - "Tooling" - ], - "keywords": [ - "privacy-preserving", - "data analysis", - "MPC", - "statistics", - "verifiable computation" - ], - "duration": 508, - "language": "en", - "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51", - "sources_youtubeId": "wCp7Zsjou7w", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt", - "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you", - "eventId": "devcon-7", - "slot_start": 1731396000000, - "slot_end": 1731396600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8", - "resources_slides": null, - "speakers": [ - "kevin-chia", - "teeramet-jern-kunpittaya" - ] - }, - "vector": [ 0, 0, 0, @@ -523711,7 +524040,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -524033,6 +524361,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -524181,8 +524510,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -524385,6 +524712,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -524412,6 +524740,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -524461,7 +524791,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -524529,7 +524858,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -524549,7 +524877,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -524557,7 +524884,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -524718,6 +525044,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -524787,7 +525114,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -524864,6 +525190,7 @@ 0, 2, 0, + 2, 0, 0, 0, @@ -524875,6 +525202,61 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mpcstats", + "sourceId": "ND3S9R", + "title": "MPCStats", + "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Tooling", + "Privacy", + "MPC", + "Public good", + "verification", + "computation", + "MPC", + "Privacy", + "Public good", + "Tooling" + ], + "keywords": [ + "privacy-preserving", + "data analysis", + "MPC", + "statistics", + "verifiable computation" + ], + "duration": 508, + "language": "en", + "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51", + "sources_youtubeId": "wCp7Zsjou7w", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt", + "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you", + "eventId": "devcon-7", + "slot_start": 1731396000000, + "slot_end": 1731396600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8", + "resources_slides": null, + "speakers": [ + "kevin-chia", + "teeramet-jern-kunpittaya" + ] + }, + "vector": [ 0, 0, 0, @@ -524885,6 +525267,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -525002,11 +525385,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -525019,50 +525400,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up", - "sourceId": "883QBY", - "title": "MUD - How we built an EVM application framework from the ground up", - "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Onchain", - "Games" - ], - "tags": [ - "DevEx", - "Frameworks", - "Gaming", - "Autonomous World", - "onchain", - "Autonomous World", - "DevEx", - "Frameworks" - ], - "language": "en", - "speakers": [ - "alvarius" - ], - "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -525173,7 +525513,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -525400,6 +525739,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -525680,6 +526021,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525747,6 +526089,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525766,6 +526109,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525773,6 +526117,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -525828,7 +526173,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -525903,13 +526247,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -526006,6 +526347,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -526079,6 +526422,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -526218,6 +526562,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -526234,9 +526579,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up", + "sourceId": "883QBY", + "title": "MUD - How we built an EVM application framework from the ground up", + "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Onchain", + "Games" + ], + "tags": [ + "DevEx", + "Frameworks", + "Gaming", + "Autonomous World", + "onchain", + "Autonomous World", + "DevEx", + "Frameworks" + ], + "language": "en", + "speakers": [ + "alvarius" + ], + "eventId": "devcon-7", + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -526348,6 +526734,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -526360,11 +526750,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -526377,39 +526765,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "mud-past-present-and-future", - "sourceId": "FE9L3P", - "title": "MUD: Past, present, and future", - "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Autonomous World", - "Frameworks", - "Gaming", - "Tooling" - ], - "language": "en", - "speakers": [ - "alvarius" - ], - "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731554400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE" - }, - "vector": [ 0, 0, 0, @@ -526422,7 +526777,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -526524,7 +526878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -527039,6 +527392,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -527113,6 +527467,33 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -527170,7 +527551,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -527254,13 +527634,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -527408,6 +527785,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -527546,9 +527924,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -527561,6 +527941,39 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "mud-past-present-and-future", + "sourceId": "FE9L3P", + "title": "MUD: Past, present, and future", + "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Autonomous World", + "Frameworks", + "Gaming", + "Tooling" + ], + "language": "en", + "speakers": [ + "alvarius" + ], + "eventId": "devcon-7", + "slot_start": 1731553200000, + "slot_end": 1731554400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE" + }, + "vector": [ 0, 0, 0, @@ -527573,6 +527986,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -527675,6 +528089,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -527713,9 +528129,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -527728,41 +528142,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "multi-party-fhe-for-multi-player-privacy", - "sourceId": "S9S8M9", - "title": "Multi-Party FHE for Multi-Player Privacy", - "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.", - "track": "Applied Cryptography", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "mp", - "fhe", - "programmable cryptography" - ], - "tags": [], - "language": "en", - "speakers": [ - "gubsheep", - "veronica-zheng", - "eduard-sanou", - "janmajaya-mall" - ], - "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731567600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI" - }, - "vector": [ 0, 0, 0, @@ -527773,7 +528152,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -527891,7 +528269,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -527950,7 +528327,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -528183,7 +528559,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -528245,7 +528620,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -528364,6 +528738,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -528444,9 +528822,14 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -528898,7 +529281,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -528911,6 +529296,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "multi-party-fhe-for-multi-player-privacy", + "sourceId": "S9S8M9", + "title": "Multi-Party FHE for Multi-Player Privacy", + "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.", + "track": "Applied Cryptography", + "type": "Panel", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "mp", + "fhe", + "programmable cryptography" + ], + "tags": [], + "language": "en", + "speakers": [ + "gubsheep", + "veronica-zheng", + "eduard-sanou", + "janmajaya-mall" + ], + "eventId": "devcon-7", + "slot_start": 1731564000000, + "slot_end": 1731567600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI" + }, + "vector": [ 0, 0, 0, @@ -528921,6 +529341,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -529039,6 +529460,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -529066,9 +529492,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -529081,43 +529505,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice", - "sourceId": "QC7FH7", - "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice", - "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Programmable", - "Cryptography" - ], - "tags": [ - "Cryptography", - "Homomorphic Encryption" - ], - "language": "en", - "speakers": [ - "gubsheep", - "riley-wong-theythem", - "eduard-sanou", - "han-jian" - ], - "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731654000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM" - }, - "vector": [ 0, 0, 0, @@ -529305,7 +529692,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -529367,6 +529753,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -529428,6 +529815,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -529600,9 +529988,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -529870,7 +530255,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -529947,7 +530331,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -530255,7 +530638,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -530268,6 +530653,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice", + "sourceId": "QC7FH7", + "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice", + "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Programmable", + "Cryptography" + ], + "tags": [ + "Cryptography", + "Homomorphic Encryption" + ], + "language": "en", + "speakers": [ + "gubsheep", + "riley-wong-theythem", + "eduard-sanou", + "han-jian" + ], + "eventId": "devcon-7", + "slot_start": 1731648600000, + "slot_end": 1731654000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM" + }, + "vector": [ 0, 0, 0, @@ -530282,6 +530704,18 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -530419,7 +530853,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -530433,48 +530866,8 @@ 0, 0, 0, - 2, 0, 0, - 0 - ] - }, - { - "session": { - "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors", - "sourceId": "KS7H3H", - "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors", - "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Open Source Software", - "Homomorphic Encryption", - "Use cases of cryptography", - "Security", - "Use Cases", - "Homomorphic Encryption", - "Open Source Software", - "Security", - "Use Cases", - "Use cases of cryptography" - ], - "language": "en", - "speakers": [ - "jean-philippe-bossuat" - ], - "eventId": "devcon-7", - "slot_start": 1731569400000, - "slot_end": 1731571200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA" - }, - "vector": [ 0, 0, 0, @@ -530781,6 +531174,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -530960,7 +531356,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -531051,6 +531446,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -531127,6 +531523,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -531214,7 +531611,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -531242,7 +531638,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531293,7 +531688,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531304,7 +531698,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531312,7 +531705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -531603,6 +531995,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -531616,8 +532009,48 @@ 0, 0, 0, + 2, 0, 0, + 0 + ] + }, + { + "session": { + "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors", + "sourceId": "KS7H3H", + "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors", + "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Open Source Software", + "Homomorphic Encryption", + "Use cases of cryptography", + "Security", + "Use Cases", + "Homomorphic Encryption", + "Open Source Software", + "Security", + "Use Cases", + "Use cases of cryptography" + ], + "language": "en", + "speakers": [ + "jean-philippe-bossuat" + ], + "eventId": "devcon-7", + "slot_start": 1731569400000, + "slot_end": 1731571200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA" + }, + "vector": [ 0, 0, 0, @@ -531628,6 +532061,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -531776,12 +532210,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -531793,41 +532225,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "my-mother-will-not-use-it", - "sourceId": "HKKFQX", - "title": "\"My mother will not use it\"", - "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Design", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Inspiration" - ], - "tags": [ - "inspiration", - "Design", - "Design Thinking", - "UI/UX" - ], - "language": "en", - "speakers": [ - "nuno-loureiro" - ], - "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731560400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc" - }, - "vector": [ 0, 0, 0, @@ -531836,7 +532233,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -532142,6 +532538,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -532314,7 +532711,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -532398,6 +532794,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -532425,6 +532822,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -532475,6 +532873,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -532485,6 +532884,24 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -532626,7 +533043,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -532710,35 +533126,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -532969,10 +533356,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -532984,6 +533373,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "my-mother-will-not-use-it", + "sourceId": "HKKFQX", + "title": "\"My mother will not use it\"", + "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Design", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Inspiration" + ], + "tags": [ + "inspiration", + "Design", + "Design Thinking", + "UI/UX" + ], + "language": "en", + "speakers": [ + "nuno-loureiro" + ], + "eventId": "devcon-7", + "slot_start": 1731559800000, + "slot_end": 1731560400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc" + }, + "vector": [ 0, 0, 0, @@ -532991,8 +533415,8 @@ 0, 0, 0, - 2, 0, + 6, 0, 0, 0, @@ -533129,7 +533553,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -533144,64 +533567,7 @@ 0, 0, 0, - 2, 0, - 0 - ] - }, - { - "session": { - "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond", - "sourceId": "8CDPFC", - "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond", - "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "Collective Intelligence", - "Conviction", - "Consensus Mechanisms", - "Civil Resistance", - "Sustainability", - "Public good", - "Regenerative Applications", - "Design Thinking", - "Civil Resistance", - "Collective Intelligence", - "Consensus Mechanisms", - "Conviction", - "Design Thinking", - "Public good", - "Regenerative Applications", - "Sustainability" - ], - "keywords": [ - "nope" - ], - "duration": 544, - "language": "en", - "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07", - "sources_youtubeId": "0A4jXL5eBaI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731410400000, - "slot_end": 1731411000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw", - "resources_slides": null, - "speakers": [ - "jeff-emmett" - ] - }, - "vector": [ 0, 0, 0, @@ -533213,7 +533579,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -533531,6 +533896,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -533689,8 +534055,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -533846,6 +534210,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -533929,6 +534294,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -533975,7 +534342,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534050,7 +534416,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534072,7 +534437,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534085,7 +534449,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534137,7 +534500,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534173,7 +534535,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534214,6 +534575,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -534291,7 +534653,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -534352,6 +534713,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -534368,6 +534730,62 @@ 0, 2, 0, + 0 + ] + }, + { + "session": { + "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond", + "sourceId": "8CDPFC", + "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond", + "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "Collective Intelligence", + "Conviction", + "Consensus Mechanisms", + "Civil Resistance", + "Sustainability", + "Public good", + "Regenerative Applications", + "Design Thinking", + "Civil Resistance", + "Collective Intelligence", + "Consensus Mechanisms", + "Conviction", + "Design Thinking", + "Public good", + "Regenerative Applications", + "Sustainability" + ], + "keywords": [ + "nope" + ], + "duration": 544, + "language": "en", + "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07", + "sources_youtubeId": "0A4jXL5eBaI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731410400000, + "slot_end": 1731411000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw", + "resources_slides": null, + "speakers": [ + "jeff-emmett" + ] + }, + "vector": [ 0, 0, 0, @@ -534379,6 +534797,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -534505,10 +534924,7 @@ 0, 0, 0, - 2, - 0, 0, - 2, 0, 0, 0, @@ -534520,51 +534936,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560", - "sourceId": "7AWG3A", - "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560", - "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Native Account Abstraction", - "RIP-7560", - "EIP-7702" - ], - "tags": [ - "In-protocol Account Abstraction", - "Rollups", - "Account Abstraction", - "eip-7702", - "Account Abstraction", - "In-protocol Account Abstraction", - "Rollups" - ], - "language": "en", - "speakers": [ - "alex-forshtat" - ], - "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731564000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -534900,6 +535275,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -535048,7 +535424,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -535188,6 +535563,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535262,6 +535638,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535283,6 +535660,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535295,6 +535673,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535341,16 +535720,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -535383,6 +535761,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535500,6 +535879,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535520,7 +535900,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -535575,6 +535954,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -535651,7 +536031,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -535714,8 +536093,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -535727,10 +536108,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560", + "sourceId": "7AWG3A", + "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560", + "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Native Account Abstraction", + "RIP-7560", + "EIP-7702" + ], + "tags": [ + "In-protocol Account Abstraction", + "Rollups", + "Account Abstraction", + "eip-7702", + "Account Abstraction", + "In-protocol Account Abstraction", + "Rollups" + ], + "language": "en", + "speakers": [ + "alex-forshtat" + ], + "eventId": "devcon-7", + "slot_start": 1731562200000, + "slot_end": 1731564000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -535864,8 +536286,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -535878,43 +536298,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs", - "sourceId": "EAABPS", - "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs", - "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Client Development", - "Teku", - "Besu", - "Ephemery" - ], - "tags": [ - "Consensus", - "Developer Infrastructure", - "User Experience" - ], - "language": "en", - "speakers": [ - "glory-justin" - ], - "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731485700000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU" - }, - "vector": [ 0, 0, 0, @@ -535930,7 +536313,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -536256,6 +536638,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -536404,7 +536787,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -536551,6 +536933,30 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -536659,7 +537065,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -536670,7 +537075,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -536839,6 +537243,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -537051,6 +537456,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -537063,6 +537470,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs", + "sourceId": "EAABPS", + "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs", + "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Client Development", + "Teku", + "Besu", + "Ephemery" + ], + "tags": [ + "Consensus", + "Developer Infrastructure", + "User Experience" + ], + "language": "en", + "speakers": [ + "glory-justin" + ], + "eventId": "devcon-7", + "slot_start": 1731484800000, + "slot_end": 1731485700000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU" + }, + "vector": [ 0, 0, 0, @@ -537078,6 +537522,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -537216,11 +537661,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -537233,46 +537676,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "navigating-developer-liability-in-open-source-code", - "sourceId": "EXNLU9", - "title": "Navigating Developer Liability in Open-Source Code", - "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "developer", - "liability" - ], - "tags": [ - "DevEx", - "Open Source Software", - "Regulation", - "developer", - "liability", - "DevEx", - "Open Source Software", - "Regulation" - ], - "language": "en", - "speakers": [ - "eva-wong" - ], - "eventId": "devcon-7", - "slot_start": 1731651000000, - "slot_end": 1731652800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU" - }, - "vector": [ 0, 0, 0, @@ -537284,7 +537687,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -537596,6 +537998,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -537763,7 +538166,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -537853,6 +538255,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -537863,6 +538266,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -537900,6 +538304,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -538042,7 +538452,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538110,7 +538519,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538119,7 +538527,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538187,7 +538594,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538406,6 +538812,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, @@ -538417,6 +538829,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "navigating-developer-liability-in-open-source-code", + "sourceId": "EXNLU9", + "title": "Navigating Developer Liability in Open-Source Code", + "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "developer", + "liability" + ], + "tags": [ + "DevEx", + "Open Source Software", + "Regulation", + "developer", + "liability", + "DevEx", + "Open Source Software", + "Regulation" + ], + "language": "en", + "speakers": [ + "eva-wong" + ], + "eventId": "devcon-7", + "slot_start": 1731651000000, + "slot_end": 1731652800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU" + }, + "vector": [ 0, 0, 0, @@ -538428,6 +538880,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -538438,7 +538891,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -538574,13 +539026,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -538591,49 +539041,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "navigating-stablecoin-yields-and-risks", - "sourceId": "YT9SMK", - "title": "Navigating Stablecoin Yields and Risks", - "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.", - "track": "Cryptoeconomics", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Stablecoin", - "DeFi" - ], - "tags": [ - "Frameworks", - "Best Practices", - "defi", - "Best Practices", - "Frameworks" - ], - "language": "en", - "speakers": [ - "ariah-klages-mundt", - "tammy-yang", - "alessandro-buser", - "colin-platt" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -538952,6 +539361,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -539122,10 +539532,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -539236,6 +539642,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539303,6 +539710,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539311,6 +539719,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539378,6 +539787,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539401,7 +539811,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -539475,7 +539884,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -539563,7 +539971,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -539631,6 +540038,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -539766,11 +540174,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -539781,8 +540191,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "navigating-stablecoin-yields-and-risks", + "sourceId": "YT9SMK", + "title": "Navigating Stablecoin Yields and Risks", + "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.", + "track": "Cryptoeconomics", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Stablecoin", + "DeFi" + ], + "tags": [ + "Frameworks", + "Best Practices", + "defi", + "Best Practices", + "Frameworks" + ], + "language": "en", + "speakers": [ + "ariah-klages-mundt", + "tammy-yang", + "alessandro-buser", + "colin-platt" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -539932,11 +540383,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -539949,38 +540398,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "neuroai-for-ai-safety", - "sourceId": "ANUNJW", - "title": "NeuroAI for AI safety", - "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Academic", - "featured": false, - "doNotRecord": false, - "keywords": [ - "d/acc" - ], - "tags": [], - "language": "en", - "speakers": [ - "patrick-mineault" - ], - "eventId": "devcon-7", - "slot_start": 1731556680000, - "slot_end": 1731557160000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -540306,6 +540724,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -540474,7 +540896,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -540584,6 +541005,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -540657,6 +541079,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -540744,6 +541167,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -541112,6 +541536,63 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "neuroai-for-ai-safety", + "sourceId": "ANUNJW", + "title": "NeuroAI for AI safety", + "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Academic", + "featured": false, + "doNotRecord": false, + "keywords": [ + "d/acc" + ], + "tags": [], + "language": "en", + "speakers": [ + "patrick-mineault" + ], + "eventId": "devcon-7", + "slot_start": 1731556680000, + "slot_end": 1731557160000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o" + }, + "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -541280,7 +541761,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -541293,38 +541773,10 @@ 0, 0, 0, - 2, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "neurotech", - "sourceId": "GMSXUV", - "title": "Neurotech", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731555480000, - "slot_end": 1731555960000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -541628,6 +542080,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -542434,6 +542888,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -542445,10 +542901,38 @@ 0, 0, 0, + 2, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "neurotech", + "sourceId": "GMSXUV", + "title": "Neurotech", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731555480000, + "slot_end": 1731555960000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -542625,10 +543109,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -542641,61 +543123,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "new-account-types-novel-user-flows-but-what-do-they-look-like-breaking-changes-to-ux-in-a-post-7702-world", - "sourceId": "P9FRCH", - "title": "New account types = novel user flows, but what do they look like? Breaking changes to UX in a post-7702 world", - "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Design", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Wallet", - "UX" - ], - "tags": [ - "ux", - "wallet", - "Account Abstraction", - "Design", - "Key Management", - "UI/UX" - ], - "language": "en", - "speakers": [ - "gregthegreek", - "cindy" - ], - "eventId": "devcon-7", - "slot_start": 1731573000000, - "slot_end": 1731574800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1igvH4fHKFwKho-LbIvoWNBLHx_rza8WlcSOHkION9JE" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -542745,10 +543172,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -543176,7 +543599,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -543470,7 +543892,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -543478,7 +543899,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -543562,19 +543982,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -543830,8 +544237,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -543844,17 +544253,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "new-account-types-novel-user-flows-but-what-do-they-look-like-breaking-changes-to-ux-in-a-post-7702-world", + "sourceId": "P9FRCH", + "title": "New account types = novel user flows, but what do they look like? Breaking changes to UX in a post-7702 world", + "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Design", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Wallet", + "UX" + ], + "tags": [ + "ux", + "wallet", + "Account Abstraction", + "Design", + "Key Management", + "UI/UX" + ], + "language": "en", + "speakers": [ + "gregthegreek", + "cindy" + ], + "eventId": "devcon-7", + "slot_start": 1731573000000, + "slot_end": 1731574800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1igvH4fHKFwKho-LbIvoWNBLHx_rza8WlcSOHkION9JE" + }, + "vector": [ 0, 0, - 2, - 2, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -543912,6 +544358,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -543981,7 +544428,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -543996,44 +544442,7 @@ 0, 0, 0, - 2, 0, - 0 - ] - }, - { - "session": { - "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum", - "sourceId": "GHVK8E", - "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum", - "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "based rollups", - "sequencing", - "composability" - ], - "tags": [ - "Fragmentation", - "Frameworks", - "Layer 2s" - ], - "language": "en", - "speakers": [ - "mteam" - ], - "eventId": "devcon-7", - "slot_start": 1731642600000, - "slot_end": 1731644400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw" - }, - "vector": [ 0, 0, 0, @@ -544041,7 +544450,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -544382,6 +544790,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -544531,7 +544940,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -544678,6 +545086,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -544685,6 +545094,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -544768,6 +545178,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -544816,7 +545227,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -544839,7 +545249,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -544878,7 +545287,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -545054,6 +545462,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -545186,6 +545597,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -545200,7 +545612,44 @@ 0, 0, 0, + 2, 0, + 0 + ] + }, + { + "session": { + "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum", + "sourceId": "GHVK8E", + "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum", + "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "based rollups", + "sequencing", + "composability" + ], + "tags": [ + "Fragmentation", + "Frameworks", + "Layer 2s" + ], + "language": "en", + "speakers": [ + "mteam" + ], + "eventId": "devcon-7", + "slot_start": 1731642600000, + "slot_end": 1731644400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw" + }, + "vector": [ 0, 0, 0, @@ -545208,6 +545657,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -545335,11 +545785,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -545352,41 +545800,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "non-native-arithmetic-via-crt-codes", - "sourceId": "B7CJU8", - "title": "Non-Native Arithmetic via CRT Codes", - "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Coding Theory", - "Math" - ], - "tags": [ - "Cryptography", - "SNARK", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "liam-eagen" - ], - "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA" - }, - "vector": [ 0, 0, 0, @@ -545397,7 +545810,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -545737,6 +546149,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -545885,7 +546298,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -546024,6 +546436,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -546046,6 +546459,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -546084,6 +546498,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -546138,8 +546553,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -546408,7 +546821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -546543,9 +546955,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -546558,6 +546972,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "non-native-arithmetic-via-crt-codes", + "sourceId": "B7CJU8", + "title": "Non-Native Arithmetic via CRT Codes", + "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Coding Theory", + "Math" + ], + "tags": [ + "Cryptography", + "SNARK", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "liam-eagen" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA" + }, + "vector": [ 0, 0, 0, @@ -546568,6 +547017,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -546691,9 +547142,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -546705,44 +547154,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities", - "sourceId": "BEWPLY", - "title": "Onchain Capital Allocation: From current mechanisms to future possbilities", - "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": true, - "doNotRecord": false, - "keywords": [ - "Mycofi" - ], - "tags": [ - "Quadratic Voting", - "Public good", - "Regenerative Applications", - "mycofi", - "Public good", - "Quadratic Voting", - "Regenerative Applications" - ], - "language": "en", - "speakers": [ - "kevin-owocki" - ], - "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731393000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE" - }, - "vector": [ 0, 0, 0, @@ -546754,7 +547165,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -547022,7 +547432,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -547098,6 +547507,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -547352,6 +547762,16 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -547591,7 +548011,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -547693,7 +548112,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -547897,7 +548315,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -547909,10 +548329,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities", + "sourceId": "BEWPLY", + "title": "Onchain Capital Allocation: From current mechanisms to future possbilities", + "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": true, + "doNotRecord": false, + "keywords": [ + "Mycofi" + ], + "tags": [ + "Quadratic Voting", + "Public good", + "Regenerative Applications", + "mycofi", + "Public good", + "Quadratic Voting", + "Regenerative Applications" + ], + "language": "en", + "speakers": [ + "kevin-owocki" + ], + "eventId": "devcon-7", + "slot_start": 1731391200000, + "slot_end": 1731393000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE" + }, + "vector": [ 0, 0, 0, - 2, 0, 0, 0, @@ -547921,6 +548378,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -548044,12 +548503,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -548061,47 +548518,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "onchain-is-the-next-online", - "sourceId": "CXZ7UT", - "title": "Onchain is the next online", - "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.", - "track": "Usability", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Account Abstraction", - "Layer 2s", - "UX", - "Wallets", - "Developer Tools" - ], - "tags": [ - "Layer 2s", - "Account Abstraction", - "Paymaster", - "creators", - "Account Abstraction", - "Layer 2s" - ], - "language": "en", - "speakers": [ - "jesse-pollak" - ], - "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ" - }, - "vector": [ 0, 0, 0, @@ -548110,7 +548526,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -548232,6 +548647,17 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -548601,7 +549027,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -548794,6 +549219,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -548814,6 +549241,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -548907,7 +549336,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -549112,6 +549540,19 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -549231,10 +549672,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -549246,6 +549689,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "onchain-is-the-next-online", + "sourceId": "CXZ7UT", + "title": "Onchain is the next online", + "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.", + "track": "Usability", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Account Abstraction", + "Layer 2s", + "UX", + "Wallets", + "Developer Tools" + ], + "tags": [ + "Layer 2s", + "Account Abstraction", + "Paymaster", + "creators", + "Account Abstraction", + "Layer 2s" + ], + "language": "en", + "speakers": [ + "jesse-pollak" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ" + }, + "vector": [ 0, 0, 0, @@ -549254,6 +549738,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -549272,8 +549757,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -549405,11 +549888,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -549420,51 +549901,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "open-challenges-in-mini-apps-and-frames", - "sourceId": "TZDRPY", - "title": "Open challenges in Mini-apps and Frames", - "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "tags": [ - "Social", - "UI/UX", - "frames", - "Social", - "UI/UX" - ], - "keywords": [ - "frames" - ], - "duration": 480, - "language": "en", - "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe", - "sources_youtubeId": "xoMfU9Gk0xc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731400800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M", - "resources_slides": null, - "speakers": [ - "david-furlong" - ] - }, - "vector": [ 0, 0, 0, @@ -549473,7 +549909,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -549796,6 +550231,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -549965,7 +550401,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -550089,6 +550524,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -550103,6 +550539,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -550263,7 +550700,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -550384,7 +550820,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -550469,6 +550904,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -550600,9 +551037,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -550613,6 +551052,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "open-challenges-in-mini-apps-and-frames", + "sourceId": "TZDRPY", + "title": "Open challenges in Mini-apps and Frames", + "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "tags": [ + "Social", + "UI/UX", + "frames", + "Social", + "UI/UX" + ], + "keywords": [ + "frames" + ], + "duration": 480, + "language": "en", + "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe", + "sources_youtubeId": "xoMfU9Gk0xc", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731400200000, + "slot_end": 1731400800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M", + "resources_slides": null, + "speakers": [ + "david-furlong" + ] + }, + "vector": [ 0, 0, 0, @@ -550621,6 +551105,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -550637,7 +551122,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -550768,13 +551252,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -550783,34 +551265,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "open-decentralized-ai", - "sourceId": "WDMSDF", - "title": "Open + Decentralized AI", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731579600000, - "slot_end": 1731580200000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -551144,6 +551599,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -551443,6 +551899,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -551563,6 +552020,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -551815,6 +552273,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -551945,6 +552404,64 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "open-decentralized-ai", + "sourceId": "WDMSDF", + "title": "Open + Decentralized AI", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731579600000, + "slot_end": 1731580200000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs" + }, + "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -552111,10 +552628,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -552127,32 +552642,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "open-source-orchestra-coffee-shop-welcome", - "sourceId": "RKELBQ", - "title": "Open-Source Orchestra coffee shop welcome", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731636000000, - "slot_end": 1731639600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0" - }, - "vector": [ 0, 0, 0, @@ -552162,7 +552651,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -553263,6 +553751,10 @@ 0, 0, 0, + 2, + 0, + 0, + 2, 0, 0, 0, @@ -553274,6 +553766,33 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "open-source-orchestra-coffee-shop-welcome", + "sourceId": "RKELBQ", + "title": "Open-Source Orchestra coffee shop welcome", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731636000000, + "slot_end": 1731639600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0" + }, + "vector": [ 0, 0, 0, @@ -553283,6 +553802,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -553455,10 +553975,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -553471,41 +553989,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "open-source-orchestra-zukaraoke-ktv", - "sourceId": "JBCULT", - "title": "Open Source Orchestra - ZuKaraoke KTV", - "description": "OSO brings karaoke to Devcon!", - "track": "Entertainment", - "type": "Music", - "expertise": "Beginner", - "audience": "Hobby", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Music", - "Karaoke" - ], - "tags": [ - "Art", - "Free Speech", - "Social" - ], - "language": "en", - "speakers": [ - "veronica" - ], - "eventId": "devcon-7", - "slot_start": 1731475800000, - "slot_end": 1731477600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q" - }, - "vector": [ 0, 0, 0, @@ -553515,7 +553998,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -554007,7 +554489,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -554272,7 +554753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -554353,7 +554833,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -554425,7 +554904,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -554621,8 +555099,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -554635,6 +555115,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "open-source-orchestra-zukaraoke-ktv", + "sourceId": "JBCULT", + "title": "Open Source Orchestra - ZuKaraoke KTV", + "description": "OSO brings karaoke to Devcon!", + "track": "Entertainment", + "type": "Music", + "expertise": "Beginner", + "audience": "Hobby", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Music", + "Karaoke" + ], + "tags": [ + "Art", + "Free Speech", + "Social" + ], + "language": "en", + "speakers": [ + "veronica" + ], + "eventId": "devcon-7", + "slot_start": 1731475800000, + "slot_end": 1731477600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -554809,7 +555340,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -554818,49 +555348,17 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "opening-ceremony", - "sourceId": "X3JSYF", - "title": "Opening Ceremony", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "skylar-weaver" - ], - "eventId": "devcon-7", - "slot_start": 1731380400000, - "slot_end": 1731381300000, - "slot_roomId": "main-stage", - "sources_youtubeId": "dMLeSMcBskU", - "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab", - "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -555038,7 +555536,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -555156,6 +555653,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -555422,6 +555920,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -555502,6 +556001,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -555573,6 +556073,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -555956,6 +556457,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -555964,17 +556466,49 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "opening-ceremony", + "sourceId": "X3JSYF", + "title": "Opening Ceremony", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "skylar-weaver" + ], + "eventId": "devcon-7", + "slot_start": 1731380400000, + "slot_end": 1731381300000, + "slot_roomId": "main-stage", + "sources_youtubeId": "dMLeSMcBskU", + "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab", + "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -556153,13 +556687,42 @@ 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, - 2, 0, 0, - 2, 0, 0, 0, @@ -556172,32 +556735,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "opening-circle", - "sourceId": "T7THRV", - "title": "Opening Circle", - "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", - "audience": "Hobby", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731394800000, - "slot_end": 1731397500000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0" - }, - "vector": [ 0, 0, 0, @@ -556207,7 +556744,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -557272,6 +557808,10 @@ 0, 0, 0, + 2, + 0, + 0, + 2, 0, 0, 0, @@ -557283,6 +557823,33 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "opening-circle", + "sourceId": "T7THRV", + "title": "Opening Circle", + "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "Beginner", + "audience": "Hobby", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731394800000, + "slot_end": 1731397500000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0" + }, + "vector": [ 0, 0, 0, @@ -557292,6 +557859,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -557501,7 +558069,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -557510,66 +558077,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt", - "sourceId": "TAEPPF", - "title": "OpSec for the Dark Forest (or how to avoid getting rekt)", - "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Privacy", - "Security", - "Hacks", - "2FA", - "dprk", - "2FA", - "Hacks", - "Privacy", - "Security" - ], - "keywords": [ - "OpSec", - "Social Engineering", - "Malware", - "0days", - "DPRK" - ], - "duration": 542, - "language": "en", - "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c", - "sources_youtubeId": "nM2BBNlIRe4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt", - "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731406200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY", - "resources_slides": null, - "speakers": [ - "pablo-sabbatella" - ] - }, - "vector": [ - 6, 0, 0, 0, @@ -558071,7 +558583,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -558308,7 +558819,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -558425,7 +558935,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558475,7 +558984,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558560,7 +559068,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558650,6 +559157,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -558658,6 +559166,68 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt", + "sourceId": "TAEPPF", + "title": "OpSec for the Dark Forest (or how to avoid getting rekt)", + "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Privacy", + "Security", + "Hacks", + "2FA", + "dprk", + "2FA", + "Hacks", + "Privacy", + "Security" + ], + "keywords": [ + "OpSec", + "Social Engineering", + "Malware", + "0days", + "DPRK" + ], + "duration": 542, + "language": "en", + "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c", + "sources_youtubeId": "nM2BBNlIRe4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt", + "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.", + "eventId": "devcon-7", + "slot_start": 1731405600000, + "slot_end": 1731406200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY", + "resources_slides": null, + "speakers": [ + "pablo-sabbatella" + ] + }, + "vector": [ + 6, + 0, + 0, 0, 0, 0, @@ -558742,7 +559312,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -558870,11 +559439,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -558887,55 +559454,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "optimism-retro-funding-so-far-so-good-so-what", - "sourceId": "QCMZS8", - "title": "Optimism Retro Funding: So Far, So Good, So What!?", - "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.", - "track": "Coordination", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "RPGF", - "Collective Intelligence", - "Open Source Software", - "grants", - "Collective Intelligence", - "Open Source Software", - "RPGF" - ], - "keywords": [ - "Data Science", - "Impact Measurement", - "Grants" - ], - "duration": 1542, - "language": "en", - "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74", - "sources_youtubeId": "MmjAhdEbnV0", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt", - "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A", - "resources_slides": null, - "speakers": [ - "carl-cervone" - ] - }, - "vector": [ 0, 0, 0, @@ -558947,7 +559465,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -559212,6 +559729,18 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -559556,6 +560085,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -559605,6 +560135,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -559689,6 +560220,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -559709,7 +560241,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -559773,7 +560304,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -559872,6 +560402,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -559942,8 +560477,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -559997,6 +560530,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, @@ -560008,6 +560547,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "optimism-retro-funding-so-far-so-good-so-what", + "sourceId": "QCMZS8", + "title": "Optimism Retro Funding: So Far, So Good, So What!?", + "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "RPGF", + "Collective Intelligence", + "Open Source Software", + "grants", + "Collective Intelligence", + "Open Source Software", + "RPGF" + ], + "keywords": [ + "Data Science", + "Impact Measurement", + "Grants" + ], + "duration": 1542, + "language": "en", + "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74", + "sources_youtubeId": "MmjAhdEbnV0", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt", + "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.", + "eventId": "devcon-7", + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A", + "resources_slides": null, + "speakers": [ + "carl-cervone" + ] + }, + "vector": [ 0, 0, 0, @@ -560019,6 +560607,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -560237,12 +560826,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -560254,45 +560841,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "optimize-zkevm-throughput-series-ii", - "sourceId": "HRDW3R", - "title": "Optimize zkEVM throughput: Series II", - "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing", - "track": "Layer 2", - "type": "Workshop", - "expertise": "Expert", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "L2" - ], - "tags": [ - "ZK-EVMs", - "EVM-equivalent", - "ZKP", - "l2", - "EVM-equivalent", - "ZK-EVMs", - "ZKP" - ], - "language": "en", - "speakers": [ - "ignasi-ramos", - "carlos-matallana" - ], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM" - }, - "vector": [ 0, 0, 0, @@ -560300,7 +560848,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -560554,6 +561101,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -560797,8 +561345,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -560827,6 +561373,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -560890,6 +561437,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -561058,6 +561606,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -561107,7 +561657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -561352,6 +561901,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -561368,6 +561918,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "optimize-zkevm-throughput-series-ii", + "sourceId": "HRDW3R", + "title": "Optimize zkEVM throughput: Series II", + "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Expert", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "L2" + ], + "tags": [ + "ZK-EVMs", + "EVM-equivalent", + "ZKP", + "l2", + "EVM-equivalent", + "ZK-EVMs", + "ZKP" + ], + "language": "en", + "speakers": [ + "ignasi-ramos", + "carlos-matallana" + ], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731576600000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM" + }, + "vector": [ 0, 0, 0, @@ -561375,12 +561964,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -561467,7 +562056,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -561597,66 +562185,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "optimizing-full-node-costs-with-monitor-tools", - "sourceId": "D9UAVG", - "title": "Optimizing full node costs with monitor tools", - "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "performance optimization", - "service level improvement" - ], - "tags": [ - "Architecture", - "Developer Infrastructure", - "Best Practices", - "service", - "level", - "improvement", - "Architecture", - "Best Practices", - "Developer Infrastructure" - ], - "language": "en", - "speakers": [ - "jsvisa" - ], - "eventId": "devcon-7", - "slot_start": 1731571800000, - "slot_end": 1731572400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, 0, 0, 0, @@ -561935,6 +562463,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -562081,7 +562611,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -562246,6 +562775,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562422,7 +562952,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -562445,7 +562974,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -562453,7 +562981,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -562497,6 +563024,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562520,6 +563048,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562606,6 +563135,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -562679,7 +563209,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -562736,8 +563265,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -562748,10 +563279,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "optimizing-full-node-costs-with-monitor-tools", + "sourceId": "D9UAVG", + "title": "Optimizing full node costs with monitor tools", + "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "performance optimization", + "service level improvement" + ], + "tags": [ + "Architecture", + "Developer Infrastructure", + "Best Practices", + "service", + "level", + "improvement", + "Architecture", + "Best Practices", + "Developer Infrastructure" + ], + "language": "en", + "speakers": [ + "jsvisa" + ], + "eventId": "devcon-7", + "slot_start": 1731571800000, + "slot_end": 1731572400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -562827,8 +563400,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -562953,11 +563524,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -562970,44 +563539,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "oracles-for-number-values", - "sourceId": "DBKAJX", - "title": "Oracles for number values", - "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Oracles" - ], - "tags": [ - "Mechanism design", - "oracle", - "Mechanism", - "design" - ], - "language": "en", - "speakers": [ - "william-george" - ], - "eventId": "devcon-7", - "slot_start": 1731659400000, - "slot_end": 1731661200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -563218,6 +563751,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -563511,7 +564045,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -563561,6 +564094,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -563583,6 +564117,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -563590,6 +564125,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -563751,7 +564287,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -563816,6 +564351,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -563963,6 +564499,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -564087,6 +564625,62 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "oracles-for-number-values", + "sourceId": "DBKAJX", + "title": "Oracles for number values", + "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Oracles" + ], + "tags": [ + "Mechanism design", + "oracle", + "Mechanism", + "design" + ], + "language": "en", + "speakers": [ + "william-george" + ], + "eventId": "devcon-7", + "slot_start": 1731659400000, + "slot_end": 1731661200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8" + }, + "vector": [ + 0, + 0, + 6, + 0, 0, 0, 0, @@ -564182,9 +564776,6 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, @@ -564306,12 +564897,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -564323,47 +564912,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world", - "sourceId": "USJSPF", - "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world", - "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ssi" - ], - "tags": [ - "ssi", - "Digital Sovereignty", - "Identity", - "Privacy" - ], - "language": "en", - "speakers": [ - "miros" - ], - "eventId": "devcon-7", - "slot_start": 1731494400000, - "slot_end": 1731495000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -564632,6 +565185,15 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -565146,8 +565708,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -565214,7 +565774,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -565299,6 +565858,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -565420,10 +565982,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -565435,11 +565999,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world", + "sourceId": "USJSPF", + "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world", + "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ssi" + ], + "tags": [ + "ssi", + "Digital Sovereignty", + "Identity", + "Privacy" + ], + "language": "en", + "speakers": [ + "miros" + ], + "eventId": "devcon-7", + "slot_start": 1731494400000, + "slot_end": 1731495000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -565538,7 +566139,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -565661,14 +566261,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -565676,51 +566274,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "panel-source-code-verification", - "sourceId": "UJJPSH", - "title": "Panel: Source Code Verification", - "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability", - "track": "Developer Experience", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Source Code Verification", - "Block Explorers" - ], - "tags": [ - "Developer Infrastructure", - "User Experience", - "blocks", - "explorer", - "Developer Infrastructure", - "User Experience" - ], - "language": "en", - "speakers": [ - "kirill-fedoseev", - "kaan-uzdogan", - "gary-thung", - "giacomo-barbieri" - ], - "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731497400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -565767,7 +566323,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -565988,6 +566543,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -566058,7 +566614,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -566225,8 +566780,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -566273,6 +566826,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -566339,6 +566894,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -566472,7 +567030,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -566510,7 +567067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -566603,7 +567159,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -566663,6 +567218,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -566784,12 +567341,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -566797,9 +567356,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "panel-source-code-verification", + "sourceId": "UJJPSH", + "title": "Panel: Source Code Verification", + "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability", + "track": "Developer Experience", + "type": "Panel", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Source Code Verification", + "Block Explorers" + ], + "tags": [ + "Developer Infrastructure", + "User Experience", + "blocks", + "explorer", + "Developer Infrastructure", + "User Experience" + ], + "language": "en", + "speakers": [ + "kirill-fedoseev", + "kaan-uzdogan", + "gary-thung", + "giacomo-barbieri" + ], + "eventId": "devcon-7", + "slot_start": 1731493800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -566847,6 +567448,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -566898,7 +567500,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -567020,9 +567621,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -567035,43 +567634,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "passkeys-the-good-the-bad-the-ugly", - "sourceId": "XFLPAR", - "title": "Passkeys : the good, the bad, the ugly", - "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "TEE" - ], - "tags": [ - "Security", - "Account Abstraction", - "TEE", - "Account Abstraction", - "Security" - ], - "language": "en", - "speakers": [ - "nicolas-bacca" - ], - "eventId": "devcon-7", - "slot_start": 1731482400000, - "slot_end": 1731484200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ" - }, - "vector": [ - 6, 0, 0, 0, @@ -567178,6 +567740,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -567344,6 +567907,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -567581,7 +568146,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -567592,6 +568156,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -567629,6 +568194,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -567721,6 +568287,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -567810,7 +568377,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -567861,7 +568427,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -568017,6 +568582,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -568138,11 +568704,12 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -568152,6 +568719,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "passkeys-the-good-the-bad-the-ugly", + "sourceId": "XFLPAR", + "title": "Passkeys : the good, the bad, the ugly", + "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "TEE" + ], + "tags": [ + "Security", + "Account Abstraction", + "TEE", + "Account Abstraction", + "Security" + ], + "language": "en", + "speakers": [ + "nicolas-bacca" + ], + "eventId": "devcon-7", + "slot_start": 1731482400000, + "slot_end": 1731484200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ" + }, + "vector": [ + 6, 0, 0, 0, @@ -568372,13 +568976,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -568389,39 +568991,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "peerdas-in-grandine", - "sourceId": "YLLNEW", - "title": "PeerDAS in Grandine", - "description": "EPF project presentation on improving PeerDAS implementation in Grandine", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Core Protocol", - "DAS", - "Data Availability", - "EIP4844" - ], - "language": "en", - "speakers": [ - "hangleang" - ], - "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731483900000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE" - }, - "vector": [ 0, 0, 0, @@ -568437,7 +569006,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -568699,6 +569267,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -568928,12 +569498,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -568979,6 +569549,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -569180,7 +569751,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -569224,11 +569794,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -569262,6 +569830,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -569491,11 +570060,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -569506,6 +570077,39 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "peerdas-in-grandine", + "sourceId": "YLLNEW", + "title": "PeerDAS in Grandine", + "description": "EPF project presentation on improving PeerDAS implementation in Grandine", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Core Protocol", + "DAS", + "Data Availability", + "EIP4844" + ], + "language": "en", + "speakers": [ + "hangleang" + ], + "eventId": "devcon-7", + "slot_start": 1731483000000, + "slot_end": 1731483900000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE" + }, + "vector": [ 0, 0, 0, @@ -569516,12 +570120,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -569725,9 +570329,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -569740,40 +570342,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "peerdas-metrics-specifications", - "sourceId": "UYPWVK", - "title": "PeerDAS metrics specifications", - "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "DevOps" - ], - "tags": [ - "Core Protocol", - "Testing", - "Tooling" - ], - "language": "en", - "speakers": [ - "ekaterina-riazantseva" - ], - "eventId": "devcon-7", - "slot_start": 1731483900000, - "slot_end": 1731484800000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ" - }, - "vector": [ 0, 0, 0, @@ -569789,7 +570357,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -570056,6 +570623,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -570286,7 +570854,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -570305,6 +570872,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -570348,9 +570916,12 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -570532,9 +571103,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -570639,6 +571208,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -570756,7 +571326,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -570848,6 +571417,10 @@ 0, 0, 0, + 2, + 0, + 2, + 0, 0, 0, 0, @@ -570858,6 +571431,41 @@ 0, 0, 0, + 0, + 0 + ] + }, + { + "session": { + "id": "peerdas-metrics-specifications", + "sourceId": "UYPWVK", + "title": "PeerDAS metrics specifications", + "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "DevOps" + ], + "tags": [ + "Core Protocol", + "Testing", + "Tooling" + ], + "language": "en", + "speakers": [ + "ekaterina-riazantseva" + ], + "eventId": "devcon-7", + "slot_start": 1731483900000, + "slot_end": 1731484800000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ" + }, + "vector": [ 0, 0, 0, @@ -570873,6 +571481,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -571075,11 +571684,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -571092,56 +571699,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "permissionless-p2p-with-the-waku-network", - "sourceId": "N9WRM3", - "title": "Permissionless P2P with The Waku Network", - "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "p2p", - "infra" - ], - "tags": [ - "Developer Infrastructure", - "Privacy", - "DePIN", - "infra", - "p2p", - "DePIN", - "Developer Infrastructure", - "Privacy" - ], - "language": "en", - "speakers": [ - "sasha" - ], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731576600000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -571423,6 +571980,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -571645,7 +572203,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -571671,7 +572228,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -571925,7 +572484,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -571988,7 +572546,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -572170,7 +572727,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -572215,9 +572771,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -572230,11 +572788,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "permissionless-p2p-with-the-waku-network", + "sourceId": "N9WRM3", + "title": "Permissionless P2P with The Waku Network", + "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.", + "track": "Cypherpunk & Privacy", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "p2p", + "infra" + ], + "tags": [ + "Developer Infrastructure", + "Privacy", + "DePIN", + "infra", + "p2p", + "DePIN", + "Developer Infrastructure", + "Privacy" + ], + "language": "en", + "speakers": [ + "sasha" + ], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731576600000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -572314,7 +572913,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -572433,11 +573031,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -572450,60 +573046,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "play-a-massive-onchain-war-game-mud-day-demo", - "sourceId": "PG3VAG", - "title": "Play a massive onchain war game! - MUD Day Demo", - "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Hobby", - "featured": false, - "doNotRecord": false, - "keywords": [ - "", - "" - ], - "tags": [ - "Autonomous World", - "Coordination", - "Gaming" - ], - "language": "en", - "speakers": [ - "stokarz" - ], - "eventId": "devcon-7", - "slot_start": 1731554700000, - "slot_end": 1731555000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -572801,6 +573343,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -572999,7 +573542,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -573051,6 +573593,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573082,6 +573625,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573144,6 +573688,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573325,6 +573870,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573334,8 +573880,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -573379,7 +573923,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -573471,6 +574014,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -573589,9 +574133,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -573604,6 +574150,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "play-a-massive-onchain-war-game-mud-day-demo", + "sourceId": "PG3VAG", + "title": "Play a massive onchain war game! - MUD Day Demo", + "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Hobby", + "featured": false, + "doNotRecord": false, + "keywords": [ + "", + "" + ], + "tags": [ + "Autonomous World", + "Coordination", + "Gaming" + ], + "language": "en", + "speakers": [ + "stokarz" + ], + "eventId": "devcon-7", + "slot_start": 1731554700000, + "slot_end": 1731555000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w" + }, + "vector": [ 0, 0, 0, @@ -573616,6 +574197,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -573788,7 +574370,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -573797,51 +574378,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop", - "sourceId": "QAQAUX", - "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop", - "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.", - "track": "Applied Cryptography", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": true, - "keywords": [ - "cryptographic primitives", - "implementation" - ], - "tags": [ - "Zk Rollups", - "Zero-Knowledge", - "Cryptography", - "implementation", - "Cryptography", - "Zero-Knowledge", - "Zk Rollups" - ], - "language": "en", - "speakers": [ - "giuseppe" - ], - "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731650400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg" - }, - "vector": [ 0, 0, 0, @@ -573852,7 +574393,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -574161,6 +574701,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -574357,7 +574898,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -574498,6 +575038,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -574541,6 +575083,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -574593,8 +575136,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -574650,7 +575191,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -574952,6 +575492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -574960,11 +575501,51 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop", + "sourceId": "QAQAUX", + "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop", + "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.", + "track": "Applied Cryptography", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": true, + "keywords": [ + "cryptographic primitives", + "implementation" + ], + "tags": [ + "Zk Rollups", + "Zero-Knowledge", + "Cryptography", + "implementation", + "Cryptography", + "Zero-Knowledge", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "giuseppe" + ], + "eventId": "devcon-7", + "slot_start": 1731645000000, + "slot_end": 1731650400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg" + }, + "vector": [ 0, 0, 0, @@ -574975,6 +575556,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -575025,7 +575607,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -575143,13 +575724,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -575160,42 +575739,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "popcraft-mud-day-demo", - "sourceId": "UDJFDV", - "title": "PopCraft - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Fully", - "on-chain", - "game" - ], - "tags": [ - "Autonomous World", - "Gaming", - "Not financial" - ], - "language": "en", - "speakers": [ - "ck" - ], - "eventId": "devcon-7", - "slot_start": 1731557100000, - "slot_end": 1731557400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw" - }, - "vector": [ 0, 0, 0, @@ -575208,14 +575751,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -575528,6 +576063,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -575712,7 +576248,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -575766,6 +576301,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -575821,6 +576358,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -576045,8 +576583,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -576174,7 +576710,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -576198,6 +576733,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -576315,11 +576851,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -576330,6 +576868,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "popcraft-mud-day-demo", + "sourceId": "UDJFDV", + "title": "PopCraft - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Fully", + "on-chain", + "game" + ], + "tags": [ + "Autonomous World", + "Gaming", + "Not financial" + ], + "language": "en", + "speakers": [ + "ck" + ], + "eventId": "devcon-7", + "slot_start": 1731557100000, + "slot_end": 1731557400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw" + }, + "vector": [ 0, 0, 0, @@ -576342,6 +576916,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -576497,7 +577072,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -576506,7 +577080,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -576514,34 +577087,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "porting-dark-forest-to-mud-mud-day-demo", - "sourceId": "VBS9CJ", - "title": "Porting Dark Forest to MUD - MUD Day Demo", - "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "ddy" - ], - "eventId": "devcon-7", - "slot_start": 1731556200000, - "slot_end": 1731556500000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4" - }, - "vector": [ 0, 0, 0, @@ -576554,7 +577099,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -576878,6 +577422,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -577059,7 +577604,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -577213,6 +577757,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -577340,6 +577886,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -577662,6 +578209,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -577670,6 +578218,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -577677,6 +578226,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "porting-dark-forest-to-mud-mud-day-demo", + "sourceId": "VBS9CJ", + "title": "Porting Dark Forest to MUD - MUD Day Demo", + "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "ddy" + ], + "eventId": "devcon-7", + "slot_start": 1731556200000, + "slot_end": 1731556500000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4" + }, + "vector": [ 0, 0, 0, @@ -577689,6 +578266,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -577844,10 +578422,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -577860,52 +578436,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users", - "sourceId": "X8VZDJ", - "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users", - "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "eip-4844", - "Gas", - "Layer 1", - "UI/UX" - ], - "keywords": [ - "1559", - "Blobs", - "4844" - ], - "duration": 434, - "language": "en", - "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107", - "sources_youtubeId": "NKGOZ154rPM", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731408000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4", - "resources_slides": null, - "speakers": [ - "matt-cutler" - ] - }, - "vector": [ 0, 0, 0, @@ -577914,7 +578444,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -578244,6 +578773,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -578424,7 +578954,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -578660,7 +579189,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -578704,7 +579232,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -578875,35 +579402,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, @@ -579062,8 +579560,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -579076,6 +579576,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users", + "sourceId": "X8VZDJ", + "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users", + "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "eip-4844", + "Gas", + "Layer 1", + "UI/UX" + ], + "keywords": [ + "1559", + "Blobs", + "4844" + ], + "duration": 434, + "language": "en", + "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107", + "sources_youtubeId": "NKGOZ154rPM", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731407400000, + "slot_end": 1731408000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4", + "resources_slides": null, + "speakers": [ + "matt-cutler" + ] + }, + "vector": [ 0, 0, 0, @@ -579084,13 +579630,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -579207,11 +579753,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -579224,41 +579768,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "power-centralisation-and-liberal-values", - "sourceId": "EJUTA3", - "title": "Power, Centralisation and Liberal Values", - "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "ahmed-gatnash" - ], - "eventId": "devcon-7", - "slot_start": 1731651000000, - "slot_end": 1731652200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -579627,6 +580142,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -579771,7 +580287,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -579865,6 +580380,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -579908,6 +580424,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -580078,6 +580595,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -580292,6 +580810,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -580408,9 +580927,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -580423,12 +580944,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "power-centralisation-and-liberal-values", + "sourceId": "EJUTA3", + "title": "Power, Centralisation and Liberal Values", + "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "ahmed-gatnash" + ], + "eventId": "devcon-7", + "slot_start": 1731651000000, + "slot_end": 1731652200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -580555,9 +581105,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -580570,42 +581118,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "practical-endgame-on-issuance-policy", - "sourceId": "TQMWK9", - "title": "Practical endgame on issuance policy", - "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Consensus", - "Economics", - "Staking", - "Tokenomics" - ], - "language": "en", - "speakers": [ - "anders-elowsson" - ], - "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -580979,6 +581493,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -581123,7 +581638,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -581347,7 +581861,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -581377,7 +581890,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -581386,7 +581898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -581471,7 +581982,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -581769,7 +582279,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -581782,8 +582294,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "practical-endgame-on-issuance-policy", + "sourceId": "TQMWK9", + "title": "Practical endgame on issuance policy", + "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Consensus", + "Economics", + "Staking", + "Tokenomics" + ], + "language": "en", + "speakers": [ + "anders-elowsson" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -581904,7 +582450,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -581913,7 +582458,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -581921,34 +582465,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "prediction-market-panel", - "sourceId": "CCZCSH", - "title": "Prediction market panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731563400000, - "slot_end": 1731564300000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -582332,6 +582849,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -582557,6 +583075,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -582586,6 +583105,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -582594,6 +583114,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -582678,6 +583199,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -583110,6 +583632,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -583118,6 +583641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -583125,7 +583649,34 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "prediction-market-panel", + "sourceId": "CCZCSH", + "title": "Prediction market panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731563400000, + "slot_end": 1731564300000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -583249,10 +583800,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -583265,47 +583814,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai", - "sourceId": "LKD3RG", - "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI", - "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Federated AI", - "Smart Contracts", - "Transparency" - ], - "tags": [ - "transparency" - ], - "language": "en", - "speakers": [ - "sudhir-upadhyay" - ], - "eventId": "devcon-7", - "slot_start": 1731564600000, - "slot_end": 1731565200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -583820,7 +584334,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -584468,8 +584981,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -584482,13 +584997,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai", + "sourceId": "LKD3RG", + "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI", + "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Federated AI", + "Smart Contracts", + "Transparency" + ], + "tags": [ + "transparency" + ], + "language": "en", + "speakers": [ + "sudhir-upadhyay" + ], + "eventId": "devcon-7", + "slot_start": 1731564600000, + "slot_end": 1731565200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU" + }, + "vector": [ 0, 0, - 2, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -584600,12 +585149,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -584617,48 +585164,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "privacy-first-cbdcs", - "sourceId": "TWMAWN", - "title": "Privacy-First CBDCs", - "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Lobby", - "featured": false, - "doNotRecord": false, - "keywords": [ - "CBDC" - ], - "tags": [ - "Payment", - "Privacy", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "joe-andrews", - "andre-omietanski" - ], - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -584879,7 +585390,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -585044,6 +585554,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -585174,7 +585685,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -585403,7 +585913,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -585508,7 +586017,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585532,7 +586040,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585713,6 +586220,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -585828,10 +586336,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -585843,12 +586353,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "privacy-first-cbdcs", + "sourceId": "TWMAWN", + "title": "Privacy-First CBDCs", + "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Lobby", + "featured": false, + "doNotRecord": false, + "keywords": [ + "CBDC" + ], + "tags": [ + "Payment", + "Privacy", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "joe-andrews", + "andre-omietanski" + ], + "eventId": "devcon-7", + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -585955,7 +586501,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -585970,69 +586515,6 @@ 0, 0, 0, - 2 - ] - }, - { - "session": { - "id": "privacy-preserving-groups", - "sourceId": "LSA3JK", - "title": "Privacy-Preserving Groups", - "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Tooling", - "DAO", - "Privacy", - "Anonymity", - "Identity", - "Open Source Software", - "ZKP", - "Zero-Knowledge", - "Use cases of cryptography", - "Public good", - "User Experience", - "groups", - "Anonymity", - "DAO", - "Identity", - "Open Source Software", - "Privacy", - "Public good", - "Tooling", - "Use cases of cryptography", - "User Experience", - "Zero-Knowledge", - "ZKP" - ], - "keywords": [ - "Groups" - ], - "duration": 464, - "language": "en", - "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8", - "sources_youtubeId": "dWQWoqJVfn8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt", - "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya", - "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731397200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM", - "resources_slides": null, - "speakers": [ - "vivian-plasencia" - ] - }, - "vector": [ 0, 0, 0, @@ -586043,7 +586525,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -586135,6 +586616,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -586430,6 +586912,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -586556,7 +587039,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -586661,6 +587143,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -586765,43 +587248,11 @@ 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, - 6, - 0, - 0, - 0, - 0, 2, 0, 0, 0, 0, - 2, - 0, - 2, - 0, 0, 0, 0, @@ -586847,7 +587298,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -586870,10 +587320,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -586881,7 +587329,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -586889,7 +587336,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -587219,7 +587665,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -587250,6 +587695,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -587264,6 +587710,69 @@ 0, 0, 0, + 2 + ] + }, + { + "session": { + "id": "privacy-preserving-groups", + "sourceId": "LSA3JK", + "title": "Privacy-Preserving Groups", + "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Tooling", + "DAO", + "Privacy", + "Anonymity", + "Identity", + "Open Source Software", + "ZKP", + "Zero-Knowledge", + "Use cases of cryptography", + "Public good", + "User Experience", + "groups", + "Anonymity", + "DAO", + "Identity", + "Open Source Software", + "Privacy", + "Public good", + "Tooling", + "Use cases of cryptography", + "User Experience", + "Zero-Knowledge", + "ZKP" + ], + "keywords": [ + "Groups" + ], + "duration": 464, + "language": "en", + "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8", + "sources_youtubeId": "dWQWoqJVfn8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt", + "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya", + "eventId": "devcon-7", + "slot_start": 1731396600000, + "slot_end": 1731397200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM", + "resources_slides": null, + "speakers": [ + "vivian-plasencia" + ] + }, + "vector": [ 0, 0, 0, @@ -587274,6 +587783,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -587336,9 +587846,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -587350,51 +587858,9 @@ 0, 0, 0, - 0, - 0 - ] - }, - { - "session": { - "id": "prize-worthy-an-ethereum-python-hackathon-guide", - "sourceId": "73J9ZG", - "title": "Prize-Worthy: An Ethereum Python Hackathon Guide", - "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Vyper", - "Solidity" - ], - "tags": [ - "Tooling", - "DevEx", - "Open Source Software", - "solidity", - "DevEx", - "Open Source Software", - "Tooling" - ], - "language": "en", - "speakers": [ - "marc-garreau" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE" - }, - "vector": [ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -587832,6 +588298,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -587914,7 +588381,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -588062,18 +588528,23 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -588094,6 +588565,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -588119,6 +588591,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -588141,8 +588614,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -588158,7 +588633,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -588227,10 +588701,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -588610,7 +589080,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -588623,9 +589095,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "prize-worthy-an-ethereum-python-hackathon-guide", + "sourceId": "73J9ZG", + "title": "Prize-Worthy: An Ethereum Python Hackathon Guide", + "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Vyper", + "Solidity" + ], + "tags": [ + "Tooling", + "DevEx", + "Open Source Software", + "solidity", + "DevEx", + "Open Source Software", + "Tooling" + ], + "language": "en", + "speakers": [ + "marc-garreau" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -588693,55 +589205,12 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "product-led-blockchain-development", - "sourceId": "8YS9LW", - "title": "Product-Led Blockchain Development", - "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "usability", - "product development" - ], - "tags": [ - "development", - "product" - ], - "language": "en", - "speakers": [ - "gregory-rocco" - ], - "eventId": "devcon-7", - "slot_start": 1731552900000, - "slot_end": 1731553500000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck" - }, - "vector": [ 0, 0, 0, @@ -588750,7 +589219,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -589192,6 +589660,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -589267,7 +589736,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -589430,6 +589898,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589438,6 +589907,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589505,6 +589975,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589752,7 +590223,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -589771,6 +590241,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -589878,81 +590349,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -590049,9 +590445,9 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -590065,38 +590461,36 @@ }, { "session": { - "id": "programmable-cryptography-and-dacc", - "sourceId": "PNA8NU", - "title": "Programmable Cryptography and d/acc", - "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "product-led-blockchain-development", + "sourceId": "8YS9LW", + "title": "Product-Led Blockchain Development", + "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.", + "track": "Usability", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc", - "programmable cryptography" + "usability", + "product development" ], "tags": [ - "Cryptography", - "Use cases of cryptography" + "development", + "product" ], "language": "en", "speakers": [ - "wei-dai", - "muthu-venkitasubramaniam" + "gregory-rocco" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ" + "slot_start": 1731552900000, + "slot_end": 1731553500000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck" }, "vector": [ 0, - 6, 0, 0, 0, @@ -590104,6 +590498,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -590518,7 +590915,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -590847,7 +591243,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -590862,7 +591257,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -591110,6 +591504,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -591234,6 +591630,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -591396,7 +591793,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -591407,6 +591803,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -591418,41 +591817,38 @@ }, { "session": { - "id": "programmable-cryptography-and-ethereum-panel", - "sourceId": "MWKMBQ", - "title": "Programmable Cryptography and Ethereum, Panel", - "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''", - "track": "Applied Cryptography", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", + "id": "programmable-cryptography-and-dacc", + "sourceId": "PNA8NU", + "title": "Programmable Cryptography and d/acc", + "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Programmable Cryptography", - "ZKP", - "MPC", - "FHE", - "ORAM", - "Obfuscation", - "Panel", - "0xPARC" + "d/acc", + "programmable cryptography" + ], + "tags": [ + "Cryptography", + "Use cases of cryptography" ], - "tags": [], "language": "en", "speakers": [ - "gubsheep", - "albert-ni", - "barry-whitehat", - "vitalik-buterin" + "wei-dai", + "muthu-venkitasubramaniam" ], "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731403800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU" + "slot_start": 1731577800000, + "slot_end": 1731579000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ" }, "vector": [ + 0, + 6, 0, 0, 0, @@ -591463,7 +591859,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -591640,14 +592035,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -591983,6 +592375,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -592210,6 +592603,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -592224,6 +592618,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -592756,13 +593151,16 @@ 0, 0, 0, - 2, 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -592776,39 +593174,48 @@ }, { "session": { - "id": "programmable-cryptography-and-smart-contract", - "sourceId": "VJEDLX", - "title": "Programmable Cryptography and Smart Contract", - "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.", - "track": "Developer Experience", - "type": "Lightning Talk", + "id": "programmable-cryptography-and-ethereum-panel", + "sourceId": "MWKMBQ", + "title": "Programmable Cryptography and Ethereum, Panel", + "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''", + "track": "Applied Cryptography", + "type": "Panel", "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Programable", - "Cryptography" - ], - "tags": [ - "DevEx", - "Cryptography", + "Programmable Cryptography", + "ZKP", "MPC", - "programmable", - "DevEx", - "MPC" + "FHE", + "ORAM", + "Obfuscation", + "Panel", + "0xPARC" ], + "tags": [], "language": "en", "speakers": [ - "shouki-tsuda" + "gubsheep", + "albert-ni", + "barry-whitehat", + "vitalik-buterin" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731472800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI" + "slot_start": 1731400200000, + "slot_end": 1731403800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -592990,8 +593397,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -593225,6 +593638,23 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -593336,7 +593766,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -593561,7 +593990,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -593578,7 +594006,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -593637,7 +594064,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -593996,28 +594422,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, @@ -594132,43 +594536,43 @@ }, { "session": { - "id": "programmable-cryptography-and-the-future-of-the-internet", - "sourceId": "JVGEDS", - "title": "Programmable Cryptography and the future of the Internet", - "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", + "id": "programmable-cryptography-and-smart-contract", + "sourceId": "VJEDLX", + "title": "Programmable Cryptography and Smart Contract", + "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [], "keywords": [ - "None" + "Programable", + "Cryptography" + ], + "tags": [ + "DevEx", + "Cryptography", + "MPC", + "programmable", + "DevEx", + "MPC" ], - "duration": 3349, "language": "en", - "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c", - "sources_youtubeId": "", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731467700000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", - "resources_slides": null, "speakers": [ - "justin-glibert" - ] + "shouki-tsuda" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731472800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -594176,7 +594580,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -594352,7 +594755,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -594696,6 +595098,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -594922,6 +595325,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -594938,6 +595342,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -594996,6 +595401,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -595354,6 +595760,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -595467,9 +595874,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 2, 0, @@ -595489,36 +595896,38 @@ }, { "session": { - "id": "programmable-cryptography-from-a-software-engineering-lens", - "sourceId": "SWD9LD", - "title": "Programmable Cryptography from a Software Engineering Lens", - "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.", - "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", - "type": "Workshop", + "id": "programmable-cryptography-and-the-future-of-the-internet", + "sourceId": "JVGEDS", + "title": "Programmable Cryptography and the future of the Internet", + "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.", + "track": "Applied Cryptography", + "type": "Talk", "expertise": "Intermediate", - "audience": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, + "tags": [], "keywords": [ - "Programmable", - "Cryptography" - ], - "tags": [ - "Cryptography" + "None" ], + "duration": 3349, "language": "en", - "speakers": [ - "aayush-gupta", - "justin-glibert", - "arnaucube", - "ahmad", - "kevin-kwok" - ], + "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c", + "sources_youtubeId": "", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731654000000, - "slot_roomId": "breakout-2", - "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg" + "slot_start": 1731465900000, + "slot_end": 1731467700000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY", + "resources_slides": null, + "speakers": [ + "justin-glibert" + ] }, "vector": [ 0, @@ -595531,11 +595940,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -595543,7 +595955,6 @@ 0, 0, 0, - 4, 0, 0, 0, @@ -595636,7 +596047,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -595788,7 +596198,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -596049,7 +596458,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -596273,7 +596681,12 @@ 0, 0, 0, - 6, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -596826,6 +597239,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -596836,7 +597250,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -596844,27 +597257,36 @@ }, { "session": { - "id": "project-mirage-mud-day-demo", - "sourceId": "BVANRC", - "title": "Project Mirage - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", + "id": "programmable-cryptography-from-a-software-engineering-lens", + "sourceId": "SWD9LD", + "title": "Programmable Cryptography from a Software Engineering Lens", + "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.", + "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Programmable", + "Cryptography" + ], + "tags": [ + "Cryptography" + ], "language": "en", "speakers": [ - "y77cao" + "aayush-gupta", + "justin-glibert", + "arnaucube", + "ahmad", + "kevin-kwok" ], "eventId": "devcon-7", - "slot_start": 1731557400000, - "slot_end": 1731557700000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M" + "slot_start": 1731648600000, + "slot_end": 1731654000000, + "slot_roomId": "breakout-2", + "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg" }, "vector": [ 0, @@ -596879,10 +597301,9 @@ 0, 0, 0, - 6, - 0, 0, 0, + 6, 0, 0, 0, @@ -596891,6 +597312,7 @@ 0, 0, 0, + 4, 0, 0, 0, @@ -596983,6 +597405,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -597053,6 +597476,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -597133,6 +597557,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -597215,7 +597640,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -597395,6 +597819,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -597620,6 +598045,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -598172,7 +598598,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -598183,6 +598608,7 @@ 0, 0, 0, + 2, 0, 0, 0 @@ -598190,64 +598616,29 @@ }, { "session": { - "id": "proof-of-personhood-panel", - "sourceId": "GVML7H", - "title": "Proof of personhood panel", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "project-mirage-mud-day-demo", + "sourceId": "BVANRC", + "title": "Project Mirage - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", "type": "Lightning Talk", - "expertise": "", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], "tags": [], "language": "en", - "speakers": [], + "speakers": [ + "y77cao" + ], "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731561000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM" + "slot_start": 1731557400000, + "slot_end": 1731557700000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M" }, "vector": [ - 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, @@ -598260,6 +598651,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -598597,6 +598989,45 @@ 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, @@ -599516,6 +599947,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -599534,45 +599966,40 @@ }, { "session": { - "id": "protec-and-attac-programmatic-execution-layer-consensus-tests", - "sourceId": "GZBP8A", - "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests", - "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "proof-of-personhood-panel", + "sourceId": "GVML7H", + "title": "Proof of personhood panel", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Python", - "pytest" - ], - "tags": [ - "Core Protocol", - "EVM-equivalent", - "Testing", - "pytest", - "Core Protocol", - "EVM-equivalent", - "Testing" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "danceratopz" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731484800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0" + "slot_start": 1731559800000, + "slot_end": 1731561000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM" }, "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -599978,7 +600405,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -600326,7 +600752,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600550,7 +600975,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600631,7 +601055,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600687,7 +601110,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -600869,9 +601291,10 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, 2, 0, @@ -600891,42 +601314,45 @@ }, { "session": { - "id": "protocol-alignment-governing-like-a-protocol", - "sourceId": "JDKAJD", - "title": "Protocol Alignment: Governing like a Protocol", - "description": "We define a protocol as *aligned* when **all stakeholders in its network agree**:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.", - "track": "Coordination", - "type": "Lightning Talk", + "id": "protec-and-attac-programmatic-execution-layer-consensus-tests", + "sourceId": "GZBP8A", + "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests", + "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "n/a" + "Python", + "pytest" ], "tags": [ - "Governance", - "Futarchy", - "Mechanism design", - "Futarchy", - "Governance", - "Mechanism design" + "Core Protocol", + "EVM-equivalent", + "Testing", + "pytest", + "Core Protocol", + "EVM-equivalent", + "Testing" ], "language": "en", "speakers": [ - "noturhandle" + "danceratopz" ], "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731490800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps" + "slot_start": 1731483000000, + "slot_end": 1731484800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0" }, "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -600934,7 +601360,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -601335,6 +601760,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -601452,7 +601878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -601669,7 +602094,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -601686,6 +602110,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -601695,7 +602123,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -601758,7 +602185,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -601908,6 +602334,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -601988,6 +602415,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -602043,6 +602471,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -602228,7 +602657,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -602241,48 +602669,48 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "protocol-guild-a-commons-funding-protocol", - "sourceId": "EJVT7E", - "title": "Protocol Guild: A commons funding protocol", - "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "protocol-alignment-governing-like-a-protocol", + "sourceId": "JDKAJD", + "title": "Protocol Alignment: Governing like a Protocol", + "description": "We define a protocol as *aligned* when **all stakeholders in its network agree**:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "ACD", - "Core Protocol", - "DAO", - "Onchain Organization", - "Game Theory" + "n/a" ], "tags": [ - "Gaming", - "theory" + "Governance", + "Futarchy", + "Mechanism design", + "Futarchy", + "Governance", + "Mechanism design" ], "language": "en", "speakers": [ - "trent-van-epps" + "noturhandle" ], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731648600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko" + "slot_start": 1731490200000, + "slot_end": 1731490800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -602290,6 +602718,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -603027,6 +603457,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -603052,6 +603483,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -603114,6 +603546,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -603128,7 +603561,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -603466,7 +603898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -603586,9 +604017,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -603601,42 +604034,44 @@ }, { "session": { - "id": "proving-liquidity-of-an-amm", - "sourceId": "AD3X38", - "title": "Proving liquidity of an AMM", - "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", + "id": "protocol-guild-a-commons-funding-protocol", + "sourceId": "EJVT7E", + "title": "Protocol Guild: A commons funding protocol", + "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Invariants" + "ACD", + "Core Protocol", + "DAO", + "Onchain Organization", + "Game Theory" ], "tags": [ - "Formal Verification", - "Reentrancy", - "invariants", - "Formal Verification", - "Reentrancy" + "Gaming", + "theory" ], "language": "en", "speakers": [ - "jochen-hoenicke" + "trent-van-epps" ], "eventId": "devcon-7", - "slot_start": 1731471000000, - "slot_end": 1731471600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8" + "slot_start": 1731646800000, + "slot_end": 1731648600000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko" }, "vector": [ - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -604485,6 +604920,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -604570,7 +605008,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -604822,7 +605259,10 @@ 0, 0, 2, - 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -604939,10 +605379,8 @@ 0, 0, 0, - 2, - 0, - 0, 0, + 2, 0, 0, 0, @@ -604955,50 +605393,39 @@ }, { "session": { - "id": "public-private-hybrid-rollups", - "sourceId": "YUFEJK", - "title": "Public-Private Hybrid Rollups", - "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.", - "track": "Layer 2", - "type": "Talk", + "id": "proving-liquidity-of-an-amm", + "sourceId": "AD3X38", + "title": "Proving liquidity of an AMM", + "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.", + "track": "Security", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developer", "featured": false, "doNotRecord": false, - "tags": [ - "Zk Rollups", - "Token bridging", - "Privacy", - "best", - "practice", - "Privacy", - "Token bridging", - "Zk Rollups" - ], "keywords": [ - "hybrid rollups", - "privacy as a best practice" + "Invariants" + ], + "tags": [ + "Formal Verification", + "Reentrancy", + "invariants", + "Formal Verification", + "Reentrancy" ], - "duration": 1396, "language": "en", - "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e", - "sources_youtubeId": "0mDlVkzde_M", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731400200000, - "slot_end": 1731402000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4", - "resources_slides": null, "speakers": [ - "adam-domurad" - ] + "jochen-hoenicke" + ], + "eventId": "devcon-7", + "slot_start": 1731471000000, + "slot_end": 1731471600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8" }, "vector": [ + 6, + 0, 0, 0, 0, @@ -605006,7 +605433,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -605807,7 +606233,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -605855,8 +606280,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -606190,7 +606613,13 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, + 2, + 0, 0, 0, 0, @@ -606304,9 +606733,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -606322,39 +606751,48 @@ }, { "session": { - "id": "putting-intents-and-users-together", - "sourceId": "YUPJGZ", - "title": "Putting Intents and Users Together", - "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.", - "track": "Usability", - "type": "Lightning Talk", + "id": "public-private-hybrid-rollups", + "sourceId": "YUFEJK", + "title": "Public-Private Hybrid Rollups", + "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.", + "track": "Layer 2", + "type": "Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Chain", - "Abstraction" - ], "tags": [ - "Rollups", - "Account Abstraction", - "Intents", - "chain", - "abstraction", - "Account Abstraction", - "Intents", - "Rollups" + "Zk Rollups", + "Token bridging", + "Privacy", + "best", + "practice", + "Privacy", + "Token bridging", + "Zk Rollups" ], - "language": "en", - "speakers": [ - "abhimanyu-shekhawat" + "keywords": [ + "hybrid rollups", + "privacy as a best practice" ], + "duration": 1396, + "language": "en", + "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e", + "sources_youtubeId": "0mDlVkzde_M", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731557400000, - "slot_end": 1731558000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc" + "slot_start": 1731400200000, + "slot_end": 1731402000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4", + "resources_slides": null, + "speakers": [ + "adam-domurad" + ] }, "vector": [ 0, @@ -606364,7 +606802,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -606890,6 +607327,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -607138,7 +607577,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -607147,11 +607585,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -607171,6 +607607,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -607218,6 +607655,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -607299,14 +607737,13 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -607553,6 +607990,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -607680,42 +608122,39 @@ }, { "session": { - "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction", - "sourceId": "QXCTMB", - "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction", - "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "putting-intents-and-users-together", + "sourceId": "YUPJGZ", + "title": "Putting Intents and Users Together", + "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Sovereign" + "Chain", + "Abstraction" ], "tags": [ - "2FA", + "Rollups", "Account Abstraction", - "Identity", - "Open Source Software", - "Political systems", - "Politics", - "Public good", - "Use Cases", - "Validiums", - "Zero-Knowledge", - "ZK-EVMs", - "ZKP" + "Intents", + "chain", + "abstraction", + "Account Abstraction", + "Intents", + "Rollups" ], "language": "en", "speakers": [ - "diego-fernandez" + "abhimanyu-shekhawat" ], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731558600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M" + "slot_start": 1731557400000, + "slot_end": 1731558000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc" }, "vector": [ 0, @@ -607724,9 +608163,10 @@ 0, 0, 0, - 6, 0, 0, + 6, + 0, 0, 0, 0, @@ -608469,7 +608909,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -608503,11 +608942,19 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -608532,11 +608979,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -608555,7 +609000,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -608563,10 +609007,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -608624,6 +609066,44 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, @@ -608792,7 +609272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -608805,7 +609284,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -608910,44 +609388,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, @@ -609021,14 +609461,17 @@ 0, 0, 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -609041,42 +609484,51 @@ }, { "session": { - "id": "reading-before-writing-an-approach-to-brain-interfaces", - "sourceId": "AECBRW", - "title": "Reading Before Writing: An Approach to Brain Interfaces", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction", + "sourceId": "QXCTMB", + "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction", + "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Sovereign" + ], + "tags": [ + "2FA", + "Account Abstraction", + "Identity", + "Open Source Software", + "Political systems", + "Politics", + "Public good", + "Use Cases", + "Validiums", + "Zero-Knowledge", + "ZK-EVMs", + "ZKP" + ], "language": "en", - "speakers": [], + "speakers": [ + "diego-fernandez" + ], "eventId": "devcon-7", - "slot_start": 1731557160000, - "slot_end": 1731557580000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c" + "slot_start": 1731556800000, + "slot_end": 1731558600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M" }, "vector": [ - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -609606,6 +610058,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -609824,6 +610277,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -609860,7 +610314,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -609884,9 +610340,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -609905,6 +610363,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -609912,8 +610371,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -609971,6 +610432,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -610138,6 +610600,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -610150,6 +610613,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -610254,6 +610718,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -610367,11 +610832,10 @@ 2, 0, 0, - 2, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -610385,47 +610849,41 @@ }, { "session": { - "id": "reading-ethereums-tea-leaves-with-xatu-data", - "sourceId": "LGXA3Q", - "title": "Reading Ethereum's Tea Leaves with Xatu data", - "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.", - "track": "Core Protocol", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Research", + "id": "reading-before-writing-an-approach-to-brain-interfaces", + "sourceId": "AECBRW", + "title": "Reading Before Writing: An Approach to Brain Interfaces", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Data", - "Analysis", - "Observability" - ], - "tags": [ - "Layer 1", - "Consensus", - "Testing", - "observability", - "Consensus", - "Layer 1", - "Testing" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "andrew-davis", - "sam-calder-mason" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731560400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM" + "slot_start": 1731557160000, + "slot_end": 1731557580000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c" }, "vector": [ + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -610956,8 +611414,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -611165,7 +611621,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -611175,7 +611630,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -611403,7 +611857,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -611614,7 +612067,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -611739,51 +612191,48 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "realigning-with-ethereum-from-l1-to-l2", - "sourceId": "PSSQCK", - "title": "(Re)aligning with Ethereum: From L1 to L2", - "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.", - "track": "Layer 2", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Product", + "id": "reading-ethereums-tea-leaves-with-xatu-data", + "sourceId": "LGXA3Q", + "title": "Reading Ethereum's Tea Leaves with Xatu data", + "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Research", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Transition", - "Ethereum Allignment", - "EVM" + "Data", + "Analysis", + "Observability" ], "tags": [ "Layer 1", - "Layer 2s", - "Values", - "EVM", + "Consensus", + "Testing", + "observability", + "Consensus", "Layer 1", - "Layer 2s", - "Values" + "Testing" ], "language": "en", "speakers": [ - "justin-drake", - "marek-olszewski", - "david-hoffman" + "andrew-davis", + "sam-calder-mason" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731492000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM" + "slot_start": 1731555000000, + "slot_end": 1731560400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM" }, "vector": [ - 0, - 0, - 0, 0, 0, 0, @@ -612216,9 +612665,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -612318,14 +612764,14 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -612545,6 +612991,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -612586,25 +613033,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, @@ -612632,7 +613060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -612729,7 +613156,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -612793,6 +613219,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -613003,6 +613430,30 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -613082,7 +613533,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -613093,6 +613543,12 @@ 2, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -613104,45 +613560,41 @@ }, { "session": { - "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost", - "sourceId": "YRTHKH", - "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost", - "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.", + "id": "realigning-with-ethereum-from-l1-to-l2", + "sourceId": "PSSQCK", + "title": "(Re)aligning with Ethereum: From L1 to L2", + "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.", "track": "Layer 2", - "type": "Talk", + "type": "Panel", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Product", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Preconfirmations" + "Transition", + "Ethereum Allignment", + "EVM" ], "tags": [ - "Architecture", - "Protocol Design", - "Scalability", - "Appchains", - "Decentralization", - "User Experience", - "MEV", - "pre-confirmations", - "Appchains", - "Architecture", - "Decentralization", - "MEV", - "Protocol Design", - "Scalability", - "User Experience" + "Layer 1", + "Layer 2s", + "Values", + "EVM", + "Layer 1", + "Layer 2s", + "Values" ], "language": "en", "speakers": [ - "daniel-marzec" + "justin-drake", + "marek-olszewski", + "david-hoffman" ], "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw" + "slot_start": 1731488400000, + "slot_end": 1731492000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM" }, "vector": [ 0, @@ -613582,7 +614034,7 @@ 0, 0, 0, - 0, + 6, 0, 0, 0, @@ -613685,6 +614137,10 @@ 0, 0, 6, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -613886,7 +614342,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -613930,7 +614385,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -613946,13 +614400,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -613986,7 +614441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -614024,7 +614478,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -614096,6 +614549,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -614213,7 +614670,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -614450,11 +614906,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -614468,37 +614924,45 @@ }, { "session": { - "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits", - "sourceId": "UCFEEN", - "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits", - "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost", + "sourceId": "YRTHKH", + "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost", + "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Stablecoins" + "Preconfirmations" ], "tags": [ - "Decentralization Improvements", - "Censorship Resistance", - "Open Source Software", - "stablecoin", - "Censorship Resistance", - "Decentralization Improvements", - "Open Source Software" + "Architecture", + "Protocol Design", + "Scalability", + "Appchains", + "Decentralization", + "User Experience", + "MEV", + "pre-confirmations", + "Appchains", + "Architecture", + "Decentralization", + "MEV", + "Protocol Design", + "Scalability", + "User Experience" ], "language": "en", "speakers": [ - "garm" + "daniel-marzec" ], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731582600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g" + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw" }, "vector": [ 0, @@ -614508,11 +614972,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -615245,7 +615710,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -615260,6 +615724,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -615289,6 +615754,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615304,6 +615770,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615338,14 +615805,12 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -615357,6 +615822,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615382,13 +615848,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -615571,6 +616037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -615695,7 +616162,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -615807,6 +616273,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -615819,53 +616286,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "redefined-interactions-transforming-user-experience-with-intents", - "sourceId": "Q3SF8Q", - "title": "Redefined Interactions: Transforming User Experience with Intents", - "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.", - "track": "Usability", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Product", + "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits", + "sourceId": "UCFEEN", + "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits", + "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "User Experience", - "Intents", - "defi", - "Intents", - "User Experience" - ], "keywords": [ - "DeFi" + "Stablecoins" + ], + "tags": [ + "Decentralization Improvements", + "Censorship Resistance", + "Open Source Software", + "stablecoin", + "Censorship Resistance", + "Decentralization Improvements", + "Open Source Software" ], - "duration": 2896, "language": "en", - "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94", - "sources_youtubeId": "hId-FQUOpJ0", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731406200000, - "slot_end": 1731409800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU", - "resources_slides": null, "speakers": [ - "agustin-grosso", - "juli-corti", - "ran-hammer", - "dominik-hell", - "shawn-odonaghue" - ] + "garm" + ], + "eventId": "devcon-7", + "slot_start": 1731582000000, + "slot_end": 1731582600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g" }, "vector": [ 0, @@ -615876,12 +616333,10 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -616409,14 +616864,10 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -616662,19 +617113,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -616728,6 +617166,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -616777,6 +617216,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -616800,7 +617240,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -617084,6 +617523,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -617169,7 +617624,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -617177,6 +617631,10 @@ 0, 0, 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -617186,34 +617644,56 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "redefining-boundaries-in-the-infinite-garden", - "sourceId": "FUZDNX", - "title": "Redefining boundaries in the Infinite Garden", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", + "id": "redefined-interactions-transforming-user-experience-with-intents", + "sourceId": "Q3SF8Q", + "title": "Redefined Interactions: Transforming User Experience with Intents", + "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.", + "track": "Usability", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "aya-miyaguchi" + "tags": [ + "User Experience", + "Intents", + "defi", + "Intents", + "User Experience" + ], + "keywords": [ + "DeFi" ], + "duration": 2896, + "language": "en", + "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94", + "sources_youtubeId": "hId-FQUOpJ0", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731382800000, - "slot_end": 1731384000000, - "slot_roomId": "main-stage", - "sources_youtubeId": "SE15rsPVHz0", - "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0", - "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M" + "slot_start": 1731406200000, + "slot_end": 1731409800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU", + "resources_slides": null, + "speakers": [ + "agustin-grosso", + "juli-corti", + "ran-hammer", + "dominik-hell", + "shawn-odonaghue" + ] }, "vector": [ 0, @@ -617222,13 +617702,9 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, 0, + 6, 0, 0, 0, @@ -617401,7 +617877,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -617764,6 +618239,11 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -617975,6 +618455,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -618013,6 +618494,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -618150,6 +618632,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -618521,12 +619004,13 @@ 2, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -618539,42 +619023,29 @@ }, { "session": { - "id": "redefining-daos-state-of-daos-in-asia", - "sourceId": "PUMYRH", - "title": "Redefining DAOs: State of DAOs in Asia", - "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.", - "track": "Coordination", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", + "id": "redefining-boundaries-in-the-infinite-garden", + "sourceId": "FUZDNX", + "title": "Redefining boundaries in the Infinite Garden", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Standards", - "Asia" - ], - "tags": [ - "Coordination", - "DAO", - "Governance", - "asia", - "Coordination", - "DAO", - "Governance" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "joseph-low", - "hazel-devjani", - "gen", - "yvonne", - "vivian-chen" + "aya-miyaguchi" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731475800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE" + "slot_start": 1731382800000, + "slot_end": 1731384000000, + "slot_roomId": "main-stage", + "sources_youtubeId": "SE15rsPVHz0", + "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0", + "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M" }, "vector": [ 0, @@ -618583,12 +619054,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -618763,6 +619234,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -619123,11 +619598,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -619412,12 +619882,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -619471,7 +619939,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -619772,7 +620239,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -619880,13 +620346,17 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -619895,53 +620365,58 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution", - "sourceId": "FKVE9X", - "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution", - "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Engineering", + "id": "redefining-daos-state-of-daos-in-asia", + "sourceId": "PUMYRH", + "title": "Redefining DAOs: State of DAOs in Asia", + "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.", + "track": "Coordination", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "RPC", - "Execution" + "Standards", + "Asia" ], "tags": [ - "Scalability", - "EVM-equivalent", - "Tooling", - "execution", - "EVM-equivalent", - "Scalability", - "Tooling" + "Coordination", + "DAO", + "Governance", + "asia", + "Coordination", + "DAO", + "Governance" ], "language": "en", "speakers": [ - "everton-fraga" + "joseph-low", + "hazel-devjani", + "gen", + "yvonne", + "vivian-chen" ], "eventId": "devcon-7", - "slot_start": 1731565200000, - "slot_end": 1731565800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw" + "slot_start": 1731472200000, + "slot_end": 1731475800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE" }, "vector": [ 0, 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -619949,6 +620424,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -620486,6 +620962,10 @@ 0, 0, 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -620694,29 +621174,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, @@ -620795,10 +621252,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -620813,7 +621272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -620853,6 +621311,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -620870,7 +621329,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -620997,7 +621455,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -621155,6 +621612,31 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -621239,13 +621721,14 @@ 0, 0, 2, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -621257,59 +621740,48 @@ }, { "session": { - "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies", - "sourceId": "JPHQYQ", - "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies", - "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Academic", + "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution", + "sourceId": "FKVE9X", + "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution", + "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Coordination", - "Political systems", - "Solarpunk", - "Regenative Ethereum", - "value", - "asian", - "Coordination", - "Political systems", - "Regenative Ethereum", - "Solarpunk" - ], "keywords": [ - "asian", - "values" + "RPC", + "Execution" + ], + "tags": [ + "Scalability", + "EVM-equivalent", + "Tooling", + "execution", + "EVM-equivalent", + "Scalability", + "Tooling" ], - "duration": 1568, "language": "en", - "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67", - "sources_youtubeId": "rhDemdcnVVE", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731390600000, - "slot_end": 1731392400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg", - "resources_slides": null, "speakers": [ - "dev-lewis" - ] + "everton-fraga" + ], + "eventId": "devcon-7", + "slot_start": 1731565200000, + "slot_end": 1731565800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw" }, "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, - 6, 0, 0, 0, @@ -622066,6 +622538,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622148,7 +622621,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622167,7 +622639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622186,6 +622657,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622197,7 +622669,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622243,6 +622714,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622369,6 +622841,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -622416,7 +622889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622427,7 +622899,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622499,7 +622970,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -622606,18 +623076,23 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -622626,25 +623101,50 @@ }, { "session": { - "id": "remix-jazz-and-blues-jam", - "sourceId": "P8DPWB", - "title": "Remix Jazz and Blues Jam", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies", + "sourceId": "JPHQYQ", + "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies", + "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Academic", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "tags": [ + "Coordination", + "Political systems", + "Solarpunk", + "Regenative Ethereum", + "value", + "asian", + "Coordination", + "Political systems", + "Regenative Ethereum", + "Solarpunk" + ], + "keywords": [ + "asian", + "values" + ], + "duration": 1568, "language": "en", - "speakers": [], + "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67", + "sources_youtubeId": "rhDemdcnVVE", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731398400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw" + "slot_start": 1731390600000, + "slot_end": 1731392400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg", + "resources_slides": null, + "speakers": [ + "dev-lewis" + ] }, "vector": [ 0, @@ -622653,9 +623153,6 @@ 0, 0, 0, - 0, - 0, - 0, 6, 0, 0, @@ -623204,6 +623701,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -623498,6 +623996,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623516,6 +624015,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623545,6 +624045,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623763,6 +624264,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623773,6 +624275,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623844,6 +624347,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -623949,8 +624453,6 @@ 0, 0, 0, - 2, - 0, 0, 2, 0, @@ -623963,6 +624465,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0 @@ -623970,9 +624474,9 @@ }, { "session": { - "id": "remix-team-jazz-jam", - "sourceId": "DFPGS9", - "title": "Remix Team Jazz Jam", + "id": "remix-jazz-and-blues-jam", + "sourceId": "P8DPWB", + "title": "Remix Jazz and Blues Jam", "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", "track": "Entertainment", "type": "Music", @@ -623985,10 +624489,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731556800000, - "slot_end": 1731564000000, + "slot_start": 1731391200000, + "slot_end": 1731398400000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M" + "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw" }, "vector": [ 0, @@ -625293,6 +625797,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -625314,37 +625822,35 @@ }, { "session": { - "id": "resilience-to-global-catastrophes", - "sourceId": "PZFHQF", - "title": "Resilience to Global Catastrophes", - "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", + "id": "remix-team-jazz-jam", + "sourceId": "DFPGS9", + "title": "Remix Team Jazz Jam", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Resilience", - "global catastrophic risk" - ], - "tags": [ - "Climate", - "DAO", - "Effective Altruism" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "david-denkenberger", - "yesh" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731582600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U" + "slot_start": 1731556800000, + "slot_end": 1731564000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 6, 0, @@ -625898,8 +626404,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -626185,7 +626689,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -626219,7 +626722,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -626274,16 +626776,15 @@ 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, @@ -626650,6 +627151,7 @@ 0, 2, 0, + 0, 2, 0, 0, @@ -626668,44 +627170,42 @@ }, { "session": { - "id": "reth-10-how-did-we-get-here-and-what-is-next", - "sourceId": "UTDCDM", - "title": "Reth 1.0: How did we get here and what is next?", - "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "resilience-to-global-catastrophes", + "sourceId": "PZFHQF", + "title": "Resilience to Global Catastrophes", + "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "rust" + "Resilience", + "global catastrophic risk" ], "tags": [ - "Core Protocol", - "Developer Infrastructure", - "Tooling", - "rust", - "Core Protocol", - "Developer Infrastructure", - "Tooling" + "Climate", + "DAO", + "Effective Altruism" ], "language": "en", "speakers": [ - "georgios-konstantopoulos" + "david-denkenberger", + "yesh" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU" + "slot_start": 1731582000000, + "slot_end": 1731582600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U" }, "vector": [ 0, + 6, 0, 0, 0, - 6, 0, 0, 0, @@ -627257,6 +627757,9 @@ 0, 0, 6, + 6, + 0, + 0, 0, 0, 0, @@ -627459,9 +627962,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -627494,7 +627995,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -627545,6 +628045,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -627578,6 +628079,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -627632,6 +628134,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -627898,7 +628402,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -628002,12 +628505,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, + 2, + 0, 0, 0, 0, @@ -628024,39 +628528,37 @@ }, { "session": { - "id": "rethinking-ethereums-account-model", - "sourceId": "GEEQXS", - "title": "Rethinking Ethereum’s account model", - "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.", + "id": "reth-10-how-did-we-get-here-and-what-is-next", + "sourceId": "UTDCDM", + "title": "Reth 1.0: How did we get here and what is next?", + "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.", "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Expert", + "type": "Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Account", - "Models" + "rust" ], "tags": [ "Core Protocol", - "Layer 1", - "Ethereum Roadmap", - "model", - "account", + "Developer Infrastructure", + "Tooling", + "rust", "Core Protocol", - "Ethereum Roadmap", - "Layer 1" + "Developer Infrastructure", + "Tooling" ], "language": "en", "speakers": [ - "will-villanueva" + "georgios-konstantopoulos" ], "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731466500000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE" + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU" }, "vector": [ 0, @@ -628615,6 +629117,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -628813,15 +629316,16 @@ 0, 0, 0, - 6, 0, 0, 0, - 2, 0, 0, 0, 0, + 2, + 0, + 2, 0, 0, 0, @@ -628854,6 +629358,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -628992,7 +629497,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -629257,9 +629761,8 @@ 0, 0, 0, - 2, - 2, 0, + 2, 0, 0, 0, @@ -629364,6 +629867,9 @@ 0, 0, 2, + 0, + 0, + 0, 2, 0, 0, @@ -629382,48 +629888,51 @@ }, { "session": { - "id": "rethinking-usability-in-a-world-of-data-ownership", - "sourceId": "RKNJED", - "title": "Rethinking usability in a world of data ownership", - "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.", - "track": "Usability", - "type": "Talk", - "expertise": "Beginner", - "audience": "", + "id": "rethinking-ethereums-account-model", + "sourceId": "GEEQXS", + "title": "Rethinking Ethereum’s account model", + "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "applications", - "social graphs", - "data ownership" + "Account", + "Models" ], "tags": [ - "data", - "ownership", - "Best Practices", - "Design Thinking", - "MPC" + "Core Protocol", + "Layer 1", + "Ethereum Roadmap", + "model", + "account", + "Core Protocol", + "Ethereum Roadmap", + "Layer 1" ], "language": "en", "speakers": [ - "rachel" + "will-villanueva" ], "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM" + "slot_start": 1731465900000, + "slot_end": 1731466500000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE" }, "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -630172,9 +630681,12 @@ 0, 0, 0, + 6, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -630185,7 +630697,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -630243,7 +630754,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -630298,7 +630808,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -630351,6 +630860,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -630465,7 +630975,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -630615,6 +631124,8 @@ 0, 0, 0, + 0, + 2, 2, 0, 0, @@ -630718,9 +631229,11 @@ 0, 0, 0, - 2, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -630730,7 +631243,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -630738,59 +631250,39 @@ }, { "session": { - "id": "rethinking-user-risks-at-l2beat", - "sourceId": "8YKV8H", - "title": "Rethinking user risks at L2BEAT", - "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", + "id": "rethinking-usability-in-a-world-of-data-ownership", + "sourceId": "RKNJED", + "title": "Rethinking usability in a world of data ownership", + "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.", + "track": "Usability", + "type": "Talk", + "expertise": "Beginner", + "audience": "", "featured": false, "doNotRecord": false, - "tags": [ - "Layer 2s", - "Token bridging", - "Security", - "trusted", - "Layer 2s", - "Security", - "Token bridging" - ], "keywords": [ - "risk", - "trust" + "applications", + "social graphs", + "data ownership" + ], + "tags": [ + "data", + "ownership", + "Best Practices", + "Design Thinking", + "MPC" ], - "duration": 523, "language": "en", - "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9", - "sources_youtubeId": "CM6e_wwieeo", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731406800000, - "slot_end": 1731407400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw", - "resources_slides": null, "speakers": [ - "piotr-szlachciak" - ] + "rachel" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM" }, "vector": [ - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -630799,6 +631291,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -631339,7 +631832,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -631350,6 +631842,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -631520,7 +632013,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -631565,6 +632057,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631586,7 +632079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -631623,6 +632115,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631677,6 +632170,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631692,7 +632186,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -631725,7 +632218,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -631845,6 +632337,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -631994,6 +632487,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -632082,7 +632582,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -632099,39 +632598,59 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 0 ] }, { "session": { - "id": "reverse-engineering-evm-bytecode-with-ghidra", - "sourceId": "GSJ8EC", - "title": "Reverse Engineering EVM Bytecode with Ghidra", - "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.", + "id": "rethinking-user-risks-at-l2beat", + "sourceId": "8YKV8H", + "title": "Rethinking user risks at L2BEAT", + "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.", "track": "Security", - "type": "Workshop", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Community", "featured": false, - "doNotRecord": true, - "keywords": [ - "Security" - ], + "doNotRecord": false, "tags": [ + "Layer 2s", + "Token bridging", "Security", - "Reversing", - "Reversing" + "trusted", + "Layer 2s", + "Security", + "Token bridging" ], - "language": "en", - "speakers": [ - "yuejie", - "louis-tsai" + "keywords": [ + "risk", + "trust" ], + "duration": 523, + "language": "en", + "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9", + "sources_youtubeId": "CM6e_wwieeo", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731659400000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0" + "slot_start": 1731406800000, + "slot_end": 1731407400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw", + "resources_slides": null, + "speakers": [ + "piotr-szlachciak" + ] }, "vector": [ 6, @@ -632693,7 +633212,7 @@ 0, 0, 0, - 6, + 0, 6, 0, 0, @@ -632873,11 +633392,13 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -632941,6 +633462,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -633046,6 +633568,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -633078,6 +633601,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -633335,7 +633859,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -633439,12 +633962,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -633457,33 +633980,36 @@ }, { "session": { - "id": "review-is-dead-long-live-review", - "sourceId": "HZUMTT", - "title": "Review is dead; long live review", - "description": "Low-quality AI outputs are overwhelming our review systems (from code review to judicial review). As AI systems get more capable, this problem gets worse. Solving alignment lets you abdicate review, but brings political and ethical problems.\r\nThe alternative to alignment is scaling human review. Researchers are designing architectures to review general intelligence but I'll present tools and systems that can be built now to scale review of AI outputs in specific domains (e.g. software, molecules)", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "", + "id": "reverse-engineering-evm-bytecode-with-ghidra", + "sourceId": "GSJ8EC", + "title": "Reverse Engineering EVM Bytecode with Ghidra", + "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.", + "track": "Security", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "AI", - "d/acc" + "Security" + ], + "tags": [ + "Security", + "Reversing", + "Reversing" ], - "tags": [], "language": "en", "speakers": [ - "evan-miyazono" + "yuejie", + "louis-tsai" ], "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1mjmEh7Mp_muTaryIzLnVyKvNQ_TDozx2Ilmslu4ZO54" + "slot_start": 1731654000000, + "slot_end": 1731659400000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0" }, "vector": [ - 0, 6, 0, 0, @@ -634044,8 +634570,9 @@ 0, 0, 0, - 6, 0, + 6, + 6, 0, 0, 0, @@ -634226,6 +634753,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -634687,6 +635215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -634790,6 +635319,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -634798,7 +635330,6 @@ 0, 0, 0, - 2, 0, 0, 0 @@ -634806,45 +635337,38 @@ }, { "session": { - "id": "revm-endgame", - "sourceId": "VEEYFZ", - "title": "Revm Endgame", - "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "review-is-dead-long-live-review", + "sourceId": "HZUMTT", + "title": "Review is dead; long live review", + "description": "Low-quality AI outputs are overwhelming our review systems (from code review to judicial review). As AI systems get more capable, this problem gets worse. Solving alignment lets you abdicate review, but brings political and ethical problems.\r\nThe alternative to alignment is scaling human review. Researchers are designing architectures to review general intelligence but I'll present tools and systems that can be built now to scale review of AI outputs in specific domains (e.g. software, molecules)", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "", "featured": false, "doNotRecord": false, "keywords": [ - "EVM" - ], - "tags": [ - "Core Protocol", - "Architecture", - "Public good", - "execution", - "client", - "Architecture", - "Core Protocol", - "Public good" + "AI", + "d/acc" ], + "tags": [], "language": "en", "speakers": [ - "dragan-rakita" + "evan-miyazono" ], "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs" + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1mjmEh7Mp_muTaryIzLnVyKvNQ_TDozx2Ilmslu4ZO54" }, "vector": [ + 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -635598,7 +636122,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -635641,7 +636164,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -635688,7 +636210,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -635776,7 +636297,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -636141,7 +636661,12 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -636157,48 +636682,54 @@ 0, 0, 0, + 2, + 0, 0, 0 ] }, { "session": { - "id": "revolutionizing-liquidity-the-cow-amm-approach", - "sourceId": "8DCP9K", - "title": "Revolutionizing Liquidity: The CoW AMM Approach", - "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency", - "track": "Cryptoeconomics", + "id": "revm-endgame", + "sourceId": "VEEYFZ", + "title": "Revm Endgame", + "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.", + "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "LVR" + "EVM" ], "tags": [ - "MEV", - "AMMs", - "lvr", - "AMMs", - "MEV" + "Core Protocol", + "Architecture", + "Public good", + "execution", + "client", + "Architecture", + "Core Protocol", + "Public good" ], "language": "en", "speakers": [ - "anna-george" + "dragan-rakita" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731565800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk" + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs" }, "vector": [ 0, 0, - 6, 0, 0, + 6, + 0, 0, 0, 0, @@ -636935,7 +637466,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -636956,6 +637486,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -636983,6 +637529,20 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -637104,6 +637664,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -637396,33 +637957,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, @@ -637499,7 +638033,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -637512,47 +638045,52 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "rip-7755-empowering-cross-chain-interactions", - "sourceId": "787TJ7", - "title": "RIP-7755: Empowering Cross-Chain Interactions", - "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.", - "track": "Layer 2", - "type": "Workshop", + "id": "revolutionizing-liquidity-the-cow-amm-approach", + "sourceId": "8DCP9K", + "title": "Revolutionizing Liquidity: The CoW AMM Approach", + "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency", + "track": "Cryptoeconomics", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Interop" + "LVR" ], "tags": [ - "Cross-L2", - "Rollups" + "MEV", + "AMMs", + "lvr", + "AMMs", + "MEV" ], "language": "en", "speakers": [ - "jack-chuma" + "anna-george" ], "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731652200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc" + "slot_start": 1731564000000, + "slot_end": 1731565800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk" }, "vector": [ 0, 0, + 6, + 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -638289,6 +638827,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -638326,7 +638866,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -638369,6 +638908,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -638486,7 +639026,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -638749,6 +639288,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -638850,8 +639391,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -638868,42 +639409,32 @@ }, { "session": { - "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks", - "sourceId": "ZFJXFP", - "title": "RLNv2: enhanced spam protection for all peer-to-peer networks", - "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.", - "track": "Cypherpunk & Privacy", + "id": "rip-7755-empowering-cross-chain-interactions", + "sourceId": "787TJ7", + "title": "RIP-7755: Empowering Cross-Chain Interactions", + "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.", + "track": "Layer 2", "type": "Workshop", "expertise": "Intermediate", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Anonymity", - "peer-to-peer networks" + "Interop" ], "tags": [ - "Privacy", - "Censorship Resistance", - "Decentralization", - "Zero-Knowledge", - "network", - "peer-to-peer", - "Censorship Resistance", - "Decentralization", - "Privacy", - "Zero-Knowledge" + "Cross-L2", + "Rollups" ], "language": "en", "speakers": [ - "franck-royer", - "alvaro" + "jack-chuma" ], "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731488400000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ" + "slot_start": 1731645000000, + "slot_end": 1731652200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc" }, "vector": [ 0, @@ -638911,6 +639442,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -639014,7 +639547,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -639657,7 +640189,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -639691,6 +640222,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -639733,7 +640266,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -639747,7 +640279,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -639762,7 +640293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -639793,7 +640323,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -639853,6 +640382,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -640109,7 +640640,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -640207,7 +640737,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -640217,6 +640746,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -640229,44 +640764,42 @@ }, { "session": { - "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs", - "sourceId": "NHERZE", - "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs", - "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.", - "track": "Coordination", - "type": "Lightning Talk", + "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks", + "sourceId": "ZFJXFP", + "title": "RLNv2: enhanced spam protection for all peer-to-peer networks", + "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.", + "track": "Cypherpunk & Privacy", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Research", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Grants Program", - "Public Goods Funding" + "Anonymity", + "peer-to-peer networks" ], "tags": [ - "Coordination", - "DAO", - "Governance", - "Regenative Ethereum", - "Public good", - "funding", - "public", - "goods", - "Coordination", - "DAO", - "Governance", - "Public good", - "Regenative Ethereum" + "Privacy", + "Censorship Resistance", + "Decentralization", + "Zero-Knowledge", + "network", + "peer-to-peer", + "Censorship Resistance", + "Decentralization", + "Privacy", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "shinya-mori" + "franck-royer", + "alvaro" ], "eventId": "devcon-7", - "slot_start": 1731640800000, - "slot_end": 1731641400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4" + "slot_start": 1731483000000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ" }, "vector": [ 0, @@ -640274,13 +640807,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -640378,6 +640911,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -641023,6 +641557,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -641098,13 +641633,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -641117,7 +641655,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641125,6 +641662,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -641155,6 +641693,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -641163,7 +641702,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641322,7 +641860,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641393,7 +641930,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -641474,7 +642010,8 @@ 0, 0, 2, - 2, + 0, + 0, 0, 0, 0, @@ -641575,8 +642112,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -641592,40 +642129,46 @@ }, { "session": { - "id": "robust-restaking-networks", - "sourceId": "MERZWK", - "title": "Robust Restaking Networks", - "description": "We study the risks of validator reuse across multiple services in a restaking protocol. We characterize the robust security of a restaking network as a function of the buffer between the costs and profits from attacks. We also provide local analogs of these guarantees that apply specifically for a target service or coalition of services. Our results suggest measures of robustness that could be exposed to the participants in a restaking protocol. Full paper: https://arxiv.org/abs/2407.21785", - "track": "Cryptoeconomics", + "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs", + "sourceId": "NHERZE", + "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs", + "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Risk", - "Measurement", - "and", - "Mitigation" + "Grants Program", + "Public Goods Funding" ], "tags": [ - "Economics", - "Restaking" + "Coordination", + "DAO", + "Governance", + "Regenative Ethereum", + "Public good", + "funding", + "public", + "goods", + "Coordination", + "DAO", + "Governance", + "Public good", + "Regenative Ethereum" ], "language": "en", "speakers": [ - "naveen-durvasula" + "shinya-mori" ], "eventId": "devcon-7", - "slot_start": 1731486000000, - "slot_end": 1731486600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/19pt0uKTgDWFeqwxxWBjlyG912sJ3Ez2L29Niax82m9w" + "slot_start": 1731640800000, + "slot_end": 1731641400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4" }, "vector": [ - 0, - 0, - 6, 0, 0, 0, @@ -641637,6 +642180,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -642190,10 +642734,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -642397,7 +642941,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -642465,10 +643008,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -642476,6 +643021,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -642521,6 +643067,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -642679,6 +643226,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -642731,7 +643279,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -642750,6 +643297,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -642829,6 +643377,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -642928,8 +643478,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -643545,6 +644095,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -643766,7 +644317,10 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -644737,6 +645291,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -645160,6 +645716,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -646270,6 +646828,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -646440,6 +646999,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -647623,6 +648185,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -647879,6 +648442,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -648983,6 +649549,7 @@ 0, 0, 0, + 0, 6, 6, 0, @@ -649172,6 +649739,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -650164,6 +650734,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -650510,6 +651082,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -651540,6 +652114,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -651948,6 +652524,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -653050,6 +653628,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -653281,6 +653860,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -655122,6 +655704,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -655763,6 +656349,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -655927,6 +656514,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -657122,6 +657712,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -657308,6 +657899,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -658485,6 +659079,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -658714,6 +659309,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -659713,6 +660311,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -660009,6 +660609,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -661192,6 +661794,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -661916,6 +662519,9 @@ 0, 0, 0, + 0, + 0, + 0, 2, 0, 0, @@ -661937,34 +662543,30 @@ }, { "session": { - "id": "securing-grandines-performance", - "sourceId": "GGWXYQ", - "title": "Securing Grandine's Performance", - "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", + "id": "securing-ethereum", + "sourceId": "9FQPCQ", + "title": "Securing Ethereum", + "description": "l", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", + "type": "Panel", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "Consensus", - "Consensus Mechanisms", - "Core Protocol", - "Cryptography", - "Security" - ], + "tags": [], "language": "en", "speakers": [ - "mercy-boma-naps-nkari", - "zarathustra" + "michael-lewellen", + "neville-grech", + "pietro-carta", + "michael-okeeffe" ], "eventId": "devcon-7", - "slot_start": 1731482100000, - "slot_end": 1731483000000, + "slot_start": 1731573000000, + "slot_end": 1731576300000, "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog" + "resources_presentation": "https://docs.google.com/presentation/d/1m_-I_-ifsaORsMAY0_k78On1s9BICet-47EDiFzpEAM" }, "vector": [ 0, @@ -661982,11 +662584,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -662286,6 +662888,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -662548,6 +663151,12 @@ 0, 6, 6, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -662706,12 +663315,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -662719,13 +663326,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -662902,7 +663507,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -663268,13 +663872,15 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -663290,42 +663896,36 @@ }, { "session": { - "id": "security-frameworks-by-seal", - "sourceId": "A7TNUF", - "title": "Security Frameworks by SEAL", - "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.", - "track": "Security", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "securing-grandines-performance", + "sourceId": "GGWXYQ", + "title": "Securing Grandine's Performance", + "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Best practices", - "Guidelines", - "Frameworks." - ], + "keywords": [], "tags": [ - "Security", - "Hacks", - "Public good", - "framework", - "Hacks", - "Public good", + "Consensus", + "Consensus Mechanisms", + "Core Protocol", + "Cryptography", "Security" ], "language": "en", "speakers": [ - "matta-the-red-guild" + "mercy-boma-naps-nkari", + "zarathustra" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic" + "slot_start": 1731482100000, + "slot_end": 1731483000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog" }, "vector": [ - 6, 0, 0, 0, @@ -663341,6 +663941,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -663602,7 +664203,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -663909,6 +664509,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -664064,14 +664666,15 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -664079,11 +664682,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -664173,7 +664778,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664228,7 +664832,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664262,6 +664865,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -664316,7 +664920,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -664632,9 +665235,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -664648,40 +665253,42 @@ }, { "session": { - "id": "security-of-fiat-shamir-transformation", - "sourceId": "VMNCS8", - "title": "Security of Fiat-Shamir transformation", - "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k", - "track": "Applied Cryptography", + "id": "security-frameworks-by-seal", + "sourceId": "A7TNUF", + "title": "Security Frameworks by SEAL", + "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.", + "track": "Security", "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "small fields", - "IOP" + "Best practices", + "Guidelines", + "Frameworks." ], "tags": [ - "Fiat-Shamir heuristic", - "STARK", "Security", - "iop", - "Fiat-Shamir heuristic", - "Security", - "STARK" + "Hacks", + "Public good", + "framework", + "Hacks", + "Public good", + "Security" ], "language": "en", "speakers": [ - "michal-zajac" + "matta-the-red-guild" ], "eventId": "devcon-7", - "slot_start": 1731482400000, - "slot_end": 1731484200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY" + "slot_start": 1731576600000, + "slot_end": 1731578400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic" }, "vector": [ + 6, 0, 0, 0, @@ -664692,7 +665299,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -664960,6 +665566,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -665263,7 +665874,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -665530,6 +666140,42 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -665549,6 +666195,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -665899,13 +666548,60 @@ 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, 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -665914,6 +666610,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "security-of-fiat-shamir-transformation", + "sourceId": "VMNCS8", + "title": "Security of Fiat-Shamir transformation", + "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "small fields", + "IOP" + ], + "tags": [ + "Fiat-Shamir heuristic", + "STARK", + "Security", + "iop", + "Fiat-Shamir heuristic", + "Security", + "STARK" + ], + "language": "en", + "speakers": [ + "michal-zajac" + ], + "eventId": "devcon-7", + "slot_start": 1731482400000, + "slot_end": 1731484200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY" + }, + "vector": [ 0, 0, 0, @@ -665924,6 +666659,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -665983,12 +666719,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -666000,57 +666734,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "security-through-obscurity-using-microdots-to-store-secrets", - "sourceId": "UHQDPU", - "title": "Security through obscurity. Using microdots to store secrets.", - "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Lobby", - "featured": false, - "doNotRecord": false, - "tags": [ - "Digital Sovereignty", - "Cryptography", - "Security", - "Hardware wallets", - "Custody", - "Cryptography", - "Custody", - "Digital Sovereignty", - "Hardware wallets", - "Security" - ], - "keywords": [ - "None" - ], - "duration": 579, - "language": "en", - "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52", - "sources_youtubeId": "3mXa1oeHzzA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731406200000, - "slot_end": 1731406800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M", - "resources_slides": null, - "speakers": [ - "jseam" - ] - }, - "vector": [ - 6, 0, 0, 0, @@ -666551,6 +667234,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666632,7 +667316,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -666709,6 +667392,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -666789,7 +667473,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -666802,7 +667485,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -666839,7 +667521,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -666924,6 +667605,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -667126,7 +667808,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -667189,6 +667870,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -667274,6 +667959,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -667284,6 +667971,57 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "security-through-obscurity-using-microdots-to-store-secrets", + "sourceId": "UHQDPU", + "title": "Security through obscurity. Using microdots to store secrets.", + "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Lobby", + "featured": false, + "doNotRecord": false, + "tags": [ + "Digital Sovereignty", + "Cryptography", + "Security", + "Hardware wallets", + "Custody", + "Cryptography", + "Custody", + "Digital Sovereignty", + "Hardware wallets", + "Security" + ], + "keywords": [ + "None" + ], + "duration": 579, + "language": "en", + "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52", + "sources_youtubeId": "3mXa1oeHzzA", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731406200000, + "slot_end": 1731406800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M", + "resources_slides": null, + "speakers": [ + "jseam" + ] + }, + "vector": [ + 6, 0, 0, 0, @@ -667351,7 +668089,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -667368,56 +668105,6 @@ 0, 0, 0, - 2 - ] - }, - { - "session": { - "id": "semaphore-v4", - "sourceId": "ZU9D8U", - "title": "Semaphore V4", - "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Privacy", - "Zero-Knowledge", - "User Experience", - "proof-of", - "membership", - "Privacy", - "User Experience", - "Zero-Knowledge" - ], - "keywords": [ - "semaphore", - "anonymity sets", - "proof of membership" - ], - "duration": 1035, - "language": "en", - "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691", - "sources_youtubeId": "OErC2MyIKjY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt", - "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.", - "eventId": "devcon-7", - "slot_start": 1731397200000, - "slot_end": 1731397800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do", - "resources_slides": null, - "speakers": [ - "cedoor" - ] - }, - "vector": [ 0, 0, 0, @@ -667428,7 +668115,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -667921,6 +668607,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -668001,7 +668688,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -668078,6 +668764,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -668090,6 +668777,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -668126,6 +668814,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -668169,11 +668858,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, 0, 0, 0, @@ -668274,7 +668961,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -668415,6 +669101,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -668527,7 +669214,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -668558,6 +669244,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -668638,92 +669325,11 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 2, 0, 0, 0, - 2, 0, 0, 0, @@ -668736,36 +669342,55 @@ 0, 0, 0, - 0 + 0, + 2 ] }, { "session": { - "id": "shadow-network-simulations", - "sourceId": "H7HCJJ", - "title": "Shadow Network Simulations", - "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.", - "track": "[CLS] EPF Day", + "id": "semaphore-v4", + "sourceId": "ZU9D8U", + "title": "Semaphore V4", + "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.", + "track": "Applied Cryptography", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], "tags": [ - "Core Protocol", - "Layer 1", - "Testing" + "Privacy", + "Zero-Knowledge", + "User Experience", + "proof-of", + "membership", + "Privacy", + "User Experience", + "Zero-Knowledge" ], - "language": "en", - "speakers": [ - "daniel-knopik" + "keywords": [ + "semaphore", + "anonymity sets", + "proof of membership" ], + "duration": 1035, + "language": "en", + "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691", + "sources_youtubeId": "OErC2MyIKjY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt", + "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.", "eventId": "devcon-7", - "slot_start": 1731485700000, - "slot_end": 1731486600000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY" + "slot_start": 1731397200000, + "slot_end": 1731397800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do", + "resources_slides": null, + "speakers": [ + "cedoor" + ] }, "vector": [ 0, @@ -668778,12 +669403,13 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -669352,9 +669978,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -669526,7 +670152,7 @@ 0, 0, 0, - 2, + 6, 0, 0, 0, @@ -669627,6 +670253,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -669750,7 +670377,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -669880,6 +670506,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -669990,6 +670617,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -670069,8 +670697,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -670086,48 +670714,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "simulating-an-ethereum-network-at-scale", - "sourceId": "FAZBAD", - "title": "Simulating an Ethereum network at scale", - "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.", - "track": "Core Protocol", - "type": "Talk", + "id": "shadow-network-simulations", + "sourceId": "H7HCJJ", + "title": "Shadow Network Simulations", + "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Networking", - "Simulation" - ], + "keywords": [], "tags": [ + "Core Protocol", "Layer 1", - "simulation", - "Layer", - "1" + "Testing" ], "language": "en", "speakers": [ - "pop", "daniel-knopik" ], "eventId": "devcon-7", - "slot_start": 1731564600000, - "slot_end": 1731566400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ" + "slot_start": 1731485700000, + "slot_end": 1731486600000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -670139,6 +670762,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -670707,7 +671335,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -670877,10 +671504,12 @@ 0, 0, 0, + 0, 6, 0, 0, 0, + 2, 0, 0, 0, @@ -670940,7 +671569,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671105,6 +671733,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -671344,7 +671973,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -671428,8 +672056,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -671446,45 +672074,38 @@ }, { "session": { - "id": "simulating-economic-systems-of-an-autonomous-world", - "sourceId": "KWKW3W", - "title": "Simulating Economic Systems of an Autonomous World", - "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "id": "simulating-an-ethereum-network-at-scale", + "sourceId": "FAZBAD", + "title": "Simulating an Ethereum network at scale", + "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.", + "track": "Core Protocol", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Token Engineering", - "Simulations", - "Complex Systems" + "Networking", + "Simulation" ], "tags": [ - "Autonomous World", - "Gaming", - "Protocol Design" + "Layer 1", + "simulation", + "Layer", + "1" ], "language": "en", "speakers": [ - "nico-rodriguez" + "pop", + "daniel-knopik" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk" + "slot_start": 1731564600000, + "slot_end": 1731566400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ" }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -671637,17 +672258,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -672084,6 +672694,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -672252,6 +672864,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -672262,7 +672875,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -672315,6 +672927,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -672326,8 +672939,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -672720,6 +673331,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -672778,11 +673405,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -672795,30 +673427,41 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje", - "sourceId": "R9KTR7", - "title": "Singer sing writer hour with adegbengaoggunbdeje", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", + "id": "simulating-economic-systems-of-an-autonomous-world", + "sourceId": "KWKW3W", + "title": "Simulating Economic Systems of an Autonomous World", + "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Token Engineering", + "Simulations", + "Complex Systems" + ], + "tags": [ + "Autonomous World", + "Gaming", + "Protocol Design" + ], "language": "en", - "speakers": [], + "speakers": [ + "nico-rodriguez" + ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731474000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE" + "slot_start": 1731577800000, + "slot_end": 1731579300000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk" }, "vector": [ 0, @@ -672830,11 +673473,10 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -672983,6 +673625,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -673610,6 +674253,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -673673,6 +674317,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -674126,9 +674772,10 @@ 2, 0, 0, - 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -674144,45 +674791,32 @@ }, { "session": { - "id": "single-slot-finality-and-the-future-of-staking", - "sourceId": "LZCP8E", - "title": "Single Slot Finality and the future of staking", - "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje", + "sourceId": "R9KTR7", + "title": "Singer sing writer hour with adegbengaoggunbdeje", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Economic", - "security" - ], - "tags": [ - "Core Protocol", - "Ethereum Roadmap", - "Home staking", - "Single-slot Finality", - "Consensus Mechanisms", - "Security", - "economy", - "Consensus Mechanisms", - "Core Protocol", - "Ethereum Roadmap", - "Home staking", - "Single-slot Finality" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "francesco" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731575400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI" + "slot_start": 1731470400000, + "slot_end": 1731474000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -674760,7 +675394,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -674922,7 +675555,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -674941,7 +675573,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -674999,7 +675630,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -675008,7 +675638,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -675116,9 +675745,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -675306,7 +675933,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -675484,11 +676110,17 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -675501,48 +676133,55 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "slangs-query-api-a-better-way-to-analyse-solidity-code", - "sourceId": "8PYLB7", - "title": "Slang’s Query API: a better way to analyse Solidity code", - "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.", - "track": "Developer Experience", + "id": "single-slot-finality-and-the-future-of-staking", + "sourceId": "LZCP8E", + "title": "Single Slot Finality and the future of staking", + "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3", + "track": "Core Protocol", "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "Parsing", - "Compiling" + "Economic", + "security" ], "tags": [ - "Developer Infrastructure", - "Tooling", - "Languages", - "compilers", - "Developer Infrastructure", - "Languages", - "Tooling" + "Core Protocol", + "Ethereum Roadmap", + "Home staking", + "Single-slot Finality", + "Consensus Mechanisms", + "Security", + "economy", + "Consensus Mechanisms", + "Core Protocol", + "Ethereum Roadmap", + "Home staking", + "Single-slot Finality" ], "language": "en", "speakers": [ - "antony-blakey" + "francesco" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731650400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo" + "slot_start": 1731573600000, + "slot_end": 1731575400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI" }, "vector": [ 0, 0, 0, + 0, 6, 0, 0, @@ -676117,6 +676756,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -676126,7 +676766,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -676282,6 +676921,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -676333,7 +676973,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -676359,6 +676998,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -676367,6 +677007,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -676376,7 +677017,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -676475,7 +677115,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -676510,7 +677152,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -676664,6 +677305,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -676841,12 +677483,12 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, - 2, 0, + 2, 0, 0, 0, @@ -676863,37 +677505,44 @@ }, { "session": { - "id": "small-brain-games-mud-day-demo", - "sourceId": "9ZBKKS", - "title": "Small Brain Games - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "slangs-query-api-a-better-way-to-analyse-solidity-code", + "sourceId": "8PYLB7", + "title": "Slang’s Query API: a better way to analyse Solidity code", + "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "Parsing", + "Compiling" + ], "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" + "Developer Infrastructure", + "Tooling", + "Languages", + "compilers", + "Developer Infrastructure", + "Languages", + "Tooling" ], "language": "en", "speakers": [ - "small-brain" + "antony-blakey" ], "eventId": "devcon-7", - "slot_start": 1731557700000, - "slot_end": 1731558000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8" + "slot_start": 1731648600000, + "slot_end": 1731650400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -676903,7 +677552,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -677033,7 +677681,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -677482,6 +678129,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -677655,6 +678303,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -677687,6 +678336,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -677729,6 +678379,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -677740,8 +678391,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -677864,6 +678513,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -678194,13 +678844,15 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -678214,33 +678866,32 @@ }, { "session": { - "id": "smart-accounts-need-smart-sessions", - "sourceId": "SJDY99", - "title": "Smart Accounts need Smart Sessions", - "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "small-brain-games-mud-day-demo", + "sourceId": "9ZBKKS", + "title": "Small Brain Games - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "standards", - "wallets", - "interoperability" - ], + "keywords": [], "tags": [ - "interoperability" + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" ], "language": "en", "speakers": [ - "pedro-gomes" + "small-brain" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM" + "slot_start": 1731557700000, + "slot_end": 1731558000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8" }, "vector": [ 0, @@ -678251,11 +678902,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -678385,6 +679037,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -678830,7 +679483,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -679095,6 +679747,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -679374,7 +680029,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -679544,7 +680198,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -679554,6 +680207,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -679566,37 +680221,33 @@ }, { "session": { - "id": "smart-contracts-with-privacy-case-study-buying-renewable-power", - "sourceId": "F9PWUP", - "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power", - "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!", - "track": "Real World Ethereum", + "id": "smart-accounts-need-smart-sessions", + "sourceId": "SJDY99", + "title": "Smart Accounts need Smart Sessions", + "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.", + "track": "Usability", "type": "Talk", "expertise": "Intermediate", - "audience": "Business", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Enterprise" + "standards", + "wallets", + "interoperability" ], "tags": [ - "Privacy", - "Zero-Knowledge", - "Use Cases", - "enterprise", - "Privacy", - "Use Cases", - "Zero-Knowledge" + "interoperability" ], "language": "en", "speakers": [ - "paul-brody" + "pedro-gomes" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8" + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM" }, "vector": [ 0, @@ -679605,6 +680256,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -680187,6 +680840,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -680350,7 +681004,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -680417,7 +681070,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -680455,7 +681107,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -680734,6 +681385,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -680821,7 +681474,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -680900,10 +681552,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -680917,47 +681569,45 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements", - "sourceId": "SFY3FB", - "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements", - "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "smart-contracts-with-privacy-case-study-buying-renewable-power", + "sourceId": "F9PWUP", + "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power", + "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Business", "featured": false, "doNotRecord": false, "keywords": [ - "Lunarpunk", - "Culture" + "Enterprise" ], "tags": [ - "Coordination", - "Anonymity", - "Solarpunk", - "Ethereum for Good", - "Social", - "culture", - "Anonymity", - "Coordination", - "Ethereum for Good", - "Social", - "Solarpunk" + "Privacy", + "Zero-Knowledge", + "Use Cases", + "enterprise", + "Privacy", + "Use Cases", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "manualzuru" + "paul-brody" ], "eventId": "devcon-7", - "slot_start": 1731496800000, - "slot_end": 1731497400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o" + "slot_start": 1731493800000, + "slot_end": 1731495600000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8" }, "vector": [ 0, @@ -680965,6 +681615,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -681549,6 +682200,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -681712,6 +682365,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -681725,7 +682379,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681779,6 +682432,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681816,6 +682470,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -681824,8 +682479,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -681854,7 +682507,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681879,7 +682531,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -681936,7 +682587,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -682186,6 +682836,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -682278,42 +682930,53 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "solidity-inline-assembly-for-developer-experience", - "sourceId": "F7XJZW", - "title": "Solidity Inline-Assembly for Developer Experience", - "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", + "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements", + "sourceId": "SFY3FB", + "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements", + "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Solidity" + "Lunarpunk", + "Culture" ], "tags": [ - "Gas", - "Account Abstraction", - "solidity", - "Account Abstraction", - "Gas" + "Coordination", + "Anonymity", + "Solarpunk", + "Ethereum for Good", + "Social", + "culture", + "Anonymity", + "Coordination", + "Ethereum for Good", + "Social", + "Solarpunk" ], "language": "en", "speakers": [ - "vectorized" + "manualzuru" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731578400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k" + "slot_start": 1731496800000, + "slot_end": 1731497400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o" }, "vector": [ + 0, + 0, 0, 0, 0, @@ -682904,6 +683567,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -683080,6 +683744,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -683104,7 +683769,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683179,6 +683843,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -683207,6 +683873,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -683231,6 +683898,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -683283,11 +683951,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -683417,7 +684085,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -683622,14 +684289,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, - 0, - 0, 0, 0, 0 @@ -683637,36 +684302,35 @@ }, { "session": { - "id": "solidity-then-now-and-the-future", - "sourceId": "HZ3DEF", - "title": "Solidity: Then, Now, & the Future!", - "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap", + "id": "solidity-inline-assembly-for-developer-experience", + "sourceId": "F7XJZW", + "title": "Solidity Inline-Assembly for Developer Experience", + "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.", "track": "Developer Experience", "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "Smart Contract Development", "Solidity" ], "tags": [ - "Tooling", - "Languages", + "Gas", + "Account Abstraction", "solidity", - "Languages", - "Tooling" + "Account Abstraction", + "Gas" ], "language": "en", "speakers": [ - "vishwa-mehta" + "vectorized" ], "eventId": "devcon-7", - "slot_start": 1731574800000, - "slot_end": 1731576600000, + "slot_start": 1731576600000, + "slot_end": 1731578400000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA" + "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k" }, "vector": [ 0, @@ -684260,10 +684924,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -684429,7 +685093,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684464,6 +685127,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -684505,7 +685169,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684643,6 +685306,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -684974,7 +685642,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -684983,6 +685650,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -684992,44 +685660,41 @@ }, { "session": { - "id": "solo-staking-in-the-dark-forest-a-survival-guide", - "sourceId": "REJ3SW", - "title": "Solo staking in the dark forest: a survival guide", - "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", + "id": "solidity-then-now-and-the-future", + "sourceId": "HZ3DEF", + "title": "Solidity: Then, Now, & the Future!", + "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Metadata" + "Smart Contract Development", + "Solidity" ], "tags": [ - "Staking", - "Privacy", - "Security", - "MEV", - "metadata", - "MEV", - "Privacy", - "Security" + "Tooling", + "Languages", + "solidity", + "Languages", + "Tooling" ], "language": "en", "speakers": [ - "qianchen-q-yu" + "vishwa-mehta" ], "eventId": "devcon-7", - "slot_start": 1731639900000, - "slot_end": 1731640500000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg" + "slot_start": 1731574800000, + "slot_end": 1731576600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA" }, "vector": [ 0, 0, 0, - 0, 6, 0, 0, @@ -685618,6 +686283,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -685765,9 +686434,7 @@ 0, 0, 0, - 6, 0, - 6, 0, 0, 0, @@ -685789,6 +686456,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -685864,6 +686532,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -685882,7 +686551,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -685894,7 +686562,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -686132,6 +686799,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -686249,7 +686918,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -686333,11 +687001,13 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -686349,46 +687019,44 @@ }, { "session": { - "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem", - "sourceId": "QKRCF7", - "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem", - "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", + "id": "solo-staking-in-the-dark-forest-a-survival-guide", + "sourceId": "REJ3SW", + "title": "Solo staking in the dark forest: a survival guide", + "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "DeFi", - "Cross-chain", - "Aggregation" + "Metadata" ], "tags": [ - "Fragmentation", - "UI/UX", - "Account Abstraction", - "defi", - "cross-chain", - "aggregation", - "Account Abstraction", - "Fragmentation", - "UI/UX" + "Staking", + "Privacy", + "Security", + "MEV", + "metadata", + "MEV", + "Privacy", + "Security" ], "language": "en", "speakers": [ - "sunny-aggarwal" + "qianchen-q-yu" ], "eventId": "devcon-7", - "slot_start": 1731577800000, - "slot_end": 1731579600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg" + "slot_start": 1731639900000, + "slot_end": 1731640500000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg" }, "vector": [ 0, 0, 0, + 0, 6, 0, 0, @@ -686979,6 +687647,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -687126,7 +687796,9 @@ 0, 0, 0, + 6, 0, + 6, 0, 0, 0, @@ -687168,7 +687840,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687176,7 +687847,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687184,7 +687854,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687244,6 +687913,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -687255,6 +687925,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -687318,7 +687989,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687601,7 +688271,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -687610,8 +688279,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -687687,11 +688356,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -687704,49 +688373,50 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "sovereignists-vs-globalists", - "sourceId": "ZHQPKA", - "title": "Sovereignists vs. Globalists", - "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem", + "sourceId": "QKRCF7", + "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem", + "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "Vision", - "future", - "resilient technologies" + "DeFi", + "Cross-chain", + "Aggregation" ], "tags": [ - "Decentralization Improvements", - "Digital Sovereignty", - "Emergency Plan", - "resiliency", - "technology", - "Decentralization Improvements", - "Digital Sovereignty", - "Emergency Plan" + "Fragmentation", + "UI/UX", + "Account Abstraction", + "defi", + "cross-chain", + "aggregation", + "Account Abstraction", + "Fragmentation", + "UI/UX" ], "language": "en", "speakers": [ - "adrian-brink" + "sunny-aggarwal" ], "eventId": "devcon-7", - "slot_start": 1731648600000, - "slot_end": 1731649200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw" + "slot_start": 1731577800000, + "slot_end": 1731579600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg" }, "vector": [ - 0, - 0, 0, 0, 0, @@ -688339,12 +689009,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -688490,7 +689160,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -688542,12 +689211,15 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -688645,7 +689317,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -688682,6 +689353,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -688690,7 +689363,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -688870,7 +689542,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -688965,6 +689636,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -688972,6 +689645,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689055,12 +689729,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0 @@ -689068,37 +689744,40 @@ }, { "session": { - "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels", - "sourceId": "L3Z78Q", - "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels", - "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.", - "track": "Layer 2", - "type": "Workshop", + "id": "sovereignists-vs-globalists", + "sourceId": "ZHQPKA", + "title": "Sovereignists vs. Globalists", + "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Hobby", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "ELI5" + "Vision", + "future", + "resilient technologies" ], "tags": [ - "Layer 2s", - "Scalability", - "ZK-EVMs", - "eli5", - "Layer 2s", - "Scalability", - "ZK-EVMs" + "Decentralization Improvements", + "Digital Sovereignty", + "Emergency Plan", + "resiliency", + "technology", + "Decentralization Improvements", + "Digital Sovereignty", + "Emergency Plan" ], "language": "en", "speakers": [ - "emily" + "adrian-brink" ], "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731394800000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8" + "slot_start": 1731648600000, + "slot_end": 1731649200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw" }, "vector": [ 0, @@ -689106,8 +689785,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -689696,12 +690373,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -689852,6 +690529,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -689895,6 +690573,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -689906,7 +690585,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -689980,7 +690658,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -690007,6 +690684,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -690051,6 +690729,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -690188,7 +690867,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -690231,6 +690909,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -690248,7 +690927,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -690404,12 +691082,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -690419,38 +691100,32 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "speedrunning-chain-abstraction-eips", - "sourceId": "UVUPRS", - "title": "Speedrunning chain abstraction EIPs", - "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.", - "track": "Usability", - "type": "Workshop", - "expertise": "Expert", - "audience": "Developer", - "featured": true, + "id": "speed-hacking-challenge", + "sourceId": "RSYU7K", + "title": "Speed Hacking Challenge", + "description": "​Prize Pool: $50,000\r\n\r\n​A High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t", + "track": "[CLS] ETH Escape - Speed Hacking Challenge", + "type": "Mixed Formats", + "expertise": "", + "audience": "Engineering", + "featured": false, "doNotRecord": false, - "keywords": [ - "ChainAbstraction", - "CredibleAccounts", - "Cross-chain" - ], - "tags": [ - "cross-chain" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "ankit-chiplunkar" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731655200000, - "slot_end": 1731660600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk" + "slot_start": 1731551400000, + "slot_end": 1731573000000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0" }, "vector": [ 0, @@ -690461,7 +691136,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -690473,6 +691147,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -691049,7 +691728,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -691668,7 +692346,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -691771,39 +692448,44 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "sszb-a-high-performance-ssz-implementation-in-rust", - "sourceId": "M3SK39", - "title": "Sszb: A High Performance SSZ Implementation in Rust", - "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem", - "track": "[CLS] EPF Day", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels", + "sourceId": "L3Z78Q", + "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels", + "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.", + "track": "Layer 2", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Hobby", "featured": false, "doNotRecord": false, "keywords": [ - "serialization", - "ssz", - "rust" + "ELI5" ], "tags": [ - "Core", - "Protocol" + "Layer 2s", + "Scalability", + "ZK-EVMs", + "eli5", + "Layer 2s", + "Scalability", + "ZK-EVMs" ], "language": "en", "speakers": [ - "ghilia-weldesselasie" + "emily" ], "eventId": "devcon-7", - "slot_start": 1731487500000, - "slot_end": 1731488400000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I" + "slot_start": 1731389400000, + "slot_end": 1731394800000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8" }, "vector": [ 0, @@ -691813,6 +692495,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -691821,7 +692505,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -692403,8 +693086,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -692614,6 +693297,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -692687,6 +693371,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -692850,8 +693535,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -692896,6 +693579,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -692955,6 +693639,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -693107,7 +693792,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -693120,6 +693804,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -693129,37 +693815,33 @@ }, { "session": { - "id": "stablecoin-technicalities-innovations-challenges-and-opportunities", - "sourceId": "XJBYKJ", - "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities", - "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, + "id": "speedrunning-chain-abstraction-eips", + "sourceId": "UVUPRS", + "title": "Speedrunning chain abstraction EIPs", + "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.", + "track": "Usability", + "type": "Workshop", + "expertise": "Expert", + "audience": "Developer", + "featured": true, "doNotRecord": false, "keywords": [ - "Stablecoins" + "ChainAbstraction", + "CredibleAccounts", + "Cross-chain" ], "tags": [ - "Use Cases", - "Remittance", - "Product-market fit", - "stablecoin", - "Product-market fit", - "Remittance", - "Use Cases" + "cross-chain" ], "language": "en", "speakers": [ - "edwin-aoki" + "ankit-chiplunkar" ], "eventId": "devcon-7", - "slot_start": 1731568200000, - "slot_end": 1731568800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M" + "slot_start": 1731655200000, + "slot_end": 1731660600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk" }, "vector": [ 0, @@ -693168,6 +693850,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -693959,7 +694643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -693980,7 +694663,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -694266,7 +694948,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -694356,7 +695037,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -694383,6 +695063,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -694463,13 +695149,13 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, 0, 0, 0, @@ -694485,48 +695171,40 @@ }, { "session": { - "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards", - "sourceId": "J3SWYT", - "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards", - "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.", - "track": "Core Protocol", + "id": "sszb-a-high-performance-ssz-implementation-in-rust", + "sourceId": "M3SK39", + "title": "Sszb: A High Performance SSZ Implementation in Rust", + "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem", + "track": "[CLS] EPF Day", "type": "Talk", "expertise": "Intermediate", - "audience": "Stakers/Validators", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "node running", - "RISC-V", - "Hardware optimization" + "serialization", + "ssz", + "rust" ], "tags": [ - "Validator Experience", - "Home staking", - "Decentralization", - "optimization", - "hardware", - "Decentralization", - "Home staking", - "Validator Experience" + "Core", + "Protocol" ], "language": "en", "speakers": [ - "aavegotch1eth", - "haurog" + "ghilia-weldesselasie" ], "eventId": "devcon-7", - "slot_start": 1731571800000, - "slot_end": 1731573600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0" + "slot_start": 1731487500000, + "slot_end": 1731488400000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I" }, "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -694538,6 +695216,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -695121,7 +695802,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -695299,7 +695979,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -695347,7 +696026,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -695363,7 +696041,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -695440,7 +696117,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -695573,6 +696249,52 @@ 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, @@ -695610,45 +696332,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, @@ -695827,13 +696510,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -695845,46 +696528,37 @@ }, { "session": { - "id": "stark-proofs-eli5", - "sourceId": "BKTYWY", - "title": "STARK proofs ELI5", - "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work", - "track": "Applied Cryptography", + "id": "stablecoin-technicalities-innovations-challenges-and-opportunities", + "sourceId": "XJBYKJ", + "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities", + "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "ZKP", - "Use cases of cryptography", - "STARK", - "eli5", - "STARK", - "Use cases of cryptography", - "ZKP" - ], "keywords": [ - "ELI5" + "Stablecoins" + ], + "tags": [ + "Use Cases", + "Remittance", + "Product-market fit", + "stablecoin", + "Product-market fit", + "Remittance", + "Use Cases" ], - "duration": 496, "language": "en", - "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161", - "sources_youtubeId": "eHPp8mFCS6E", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt", - "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.", + "speakers": [ + "edwin-aoki" + ], "eventId": "devcon-7", - "slot_start": 1731394200000, - "slot_end": 1731394800000, + "slot_start": 1731568200000, + "slot_end": 1731568800000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco", - "resources_slides": null, - "speakers": [ - "henri" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M" }, "vector": [ 0, @@ -695893,11 +696567,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -696654,7 +697329,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -696688,6 +697362,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -696701,13 +697377,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -696839,7 +697515,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -696994,6 +697669,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -697034,7 +697712,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -697082,6 +697759,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -697210,42 +697888,49 @@ }, { "session": { - "id": "start-contributing-to-economic-protocol-development", - "sourceId": "CEZPBS", - "title": "Start contributing to economic protocol development", - "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards", + "sourceId": "J3SWYT", + "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards", + "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "keywords": [ - "Introduction" + "node running", + "RISC-V", + "Hardware optimization" ], "tags": [ - "Core Protocol", - "Economics", - "introduction", - "Core Protocol", - "Economics" + "Validator Experience", + "Home staking", + "Decentralization", + "optimization", + "hardware", + "Decentralization", + "Home staking", + "Validator Experience" ], "language": "en", "speakers": [ - "julian-ma" + "aavegotch1eth", + "haurog" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731485400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M" + "slot_start": 1731571800000, + "slot_end": 1731573600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0" }, "vector": [ 0, 0, - 6, 0, 0, + 6, + 0, 0, 0, 0, @@ -697844,6 +698529,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -697999,7 +698685,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -698015,13 +698700,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -698069,6 +698754,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -698084,6 +698770,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -698160,6 +698847,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -698329,6 +699017,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -698466,7 +699155,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -698542,17 +699230,17 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -698564,64 +699252,48 @@ }, { "session": { - "id": "state-contention-rules-everything-around-me", - "sourceId": "XGHU89", - "title": "State Contention Rules Everything Around Me", - "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", + "id": "stark-proofs-eli5", + "sourceId": "BKTYWY", + "title": "STARK proofs ELI5", + "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Synchronization", - "Concurrency" - ], "tags": [ - "Layer 1", - "Architecture", - "Cross-L2", - "concurrency", - "Architecture", - "Cross-L2", - "Layer 1" + "ZKP", + "Use cases of cryptography", + "STARK", + "eli5", + "STARK", + "Use cases of cryptography", + "ZKP" ], - "language": "en", - "speakers": [ - "james-prestwich" + "keywords": [ + "ELI5" ], + "duration": 496, + "language": "en", + "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161", + "sources_youtubeId": "eHPp8mFCS6E", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt", + "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.", "eventId": "devcon-7", - "slot_start": 1731579000000, - "slot_end": 1731580800000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40" + "slot_start": 1731394200000, + "slot_end": 1731394800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco", + "resources_slides": null, + "speakers": [ + "henri" + ] }, "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -698632,6 +699304,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -699201,7 +699874,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -699227,6 +699899,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -699352,7 +700025,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -699393,13 +700065,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -699440,6 +700112,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -699487,7 +700160,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -699539,7 +700211,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -699579,6 +700250,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -699773,6 +700445,31 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -699903,6 +700600,9 @@ 0, 0, 2, + 0, + 0, + 0, 2, 0, 0, @@ -699921,36 +700621,40 @@ }, { "session": { - "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm", - "sourceId": "VDFBMT", - "title": "State Minimized Layer-2s and Why Ethereum > EVM", - "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.", - "track": "Layer 2", + "id": "start-contributing-to-economic-protocol-development", + "sourceId": "CEZPBS", + "title": "Start contributing to economic protocol development", + "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.", + "track": "Cryptoeconomics", "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "node-requirements" + "Introduction" ], "tags": [ - "Network State", - "node-requirements", - "Network", - "State" + "Core Protocol", + "Economics", + "introduction", + "Core Protocol", + "Economics" ], "language": "en", "speakers": [ - "nick-dodson" + "julian-ma" ], "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM" + "slot_start": 1731484800000, + "slot_end": 1731485400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M" }, "vector": [ + 0, + 0, + 6, 0, 0, 0, @@ -699958,7 +700662,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -700711,6 +701414,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -700726,6 +701430,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -700737,7 +701442,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -701178,8 +701882,6 @@ 0, 0, 2, - 2, - 2, 0, 0, 0, @@ -701252,13 +701954,16 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, 2, 0, 0, + 2, + 0, 0, 0, 0, @@ -701274,46 +701979,49 @@ }, { "session": { - "id": "state-of-the-ens", - "sourceId": "VBSW3N", - "title": "State of the ENS", - "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.", - "track": "Real World Ethereum", + "id": "state-contention-rules-everything-around-me", + "sourceId": "XGHU89", + "title": "State Contention Rules Everything Around Me", + "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Beginner", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Usability" + "Synchronization", + "Concurrency" ], "tags": [ - "Protocol Design", - "Identity", - "Public good", - "usability", - "Identity", - "Protocol Design", - "Public good" + "Layer 1", + "Architecture", + "Cross-L2", + "concurrency", + "Architecture", + "Cross-L2", + "Layer 1" ], "language": "en", "speakers": [ - "jeff-lau" + "james-prestwich" ], "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731640500000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw" + "slot_start": 1731579000000, + "slot_end": 1731580800000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40" }, "vector": [ 0, 0, 0, 0, + 6, + 0, + 0, 0, 0, - 6, 0, 0, 0, @@ -702063,6 +702771,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -702092,10 +702801,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -702111,6 +702818,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -702155,7 +702863,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -702199,6 +702906,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -702250,6 +702958,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -702536,7 +703245,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -702610,8 +703318,10 @@ 0, 0, 0, - 2, 0, + 0, + 0, + 2, 2, 0, 0, @@ -702630,25 +703340,34 @@ }, { "session": { - "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls", - "sourceId": "KVDNNN", - "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)", - "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "", + "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm", + "sourceId": "VDFBMT", + "title": "State Minimized Layer-2s and Why Ethereum > EVM", + "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Intermediate", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "node-requirements" + ], + "tags": [ + "Network State", + "node-requirements", + "Network", + "State" + ], "language": "en", - "speakers": [], + "speakers": [ + "nick-dodson" + ], "eventId": "devcon-7", - "slot_start": 1731650400000, - "slot_end": 1731653100000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0" + "slot_start": 1731582600000, + "slot_end": 1731583200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM" }, "vector": [ 0, @@ -702658,8 +703377,6 @@ 0, 0, 0, - 0, - 0, 6, 0, 0, @@ -703261,6 +703978,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -703442,6 +704160,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -703881,6 +704600,9 @@ 0, 0, 0, + 2, + 2, + 2, 0, 0, 0, @@ -703956,6 +704678,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -703974,39 +704697,37 @@ }, { "session": { - "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations", - "sourceId": "MVJFDX", - "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations", - "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.", - "track": "Cypherpunk & Privacy", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Product", + "id": "state-of-the-ens", + "sourceId": "VBSW3N", + "title": "State of the ENS", + "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "Legal" + "Usability" ], "tags": [ - "Frameworks", - "Privacy", - "Censorship Resistance", - "legal", - "Censorship Resistance", - "Frameworks", - "Privacy" + "Protocol Design", + "Identity", + "Public good", + "usability", + "Identity", + "Protocol Design", + "Public good" ], "language": "en", "speakers": [ - "fatemeh-fannizadeh", - "andre-omietanski", - "amal-ibraymi" + "jeff-lau" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731582000000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA" + "slot_start": 1731638700000, + "slot_end": 1731640500000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw" }, "vector": [ 0, @@ -704014,11 +704735,8 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, + 6, 0, 0, 0, @@ -704531,7 +705249,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -704615,8 +705332,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -704624,6 +705339,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -704803,8 +705519,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -704853,7 +705571,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -704896,21 +705613,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -705239,14 +705941,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -705269,6 +705963,22 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -705310,7 +706020,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -705318,6 +706027,18 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -705327,45 +706048,43 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "superliquid-mechanisms-for-decentralized-stablecoins", - "sourceId": "SLNQ8K", - "title": "Superliquid Mechanisms for Decentralized Stablecoins", - "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", + "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls", + "sourceId": "KVDNNN", + "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)", + "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Stablecoins", - "DeFi" - ], - "tags": [ - "Mechanism design", - "Economics", - "AMMs", - "defi", - "AMMs", - "Economics", - "Mechanism design" - ], + "keywords": [], + "tags": [], "language": "en", - "speakers": [ - "ariah-klages-mundt" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU" + "slot_start": 1731650400000, + "slot_end": 1731653100000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 6, @@ -705857,7 +706576,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -706112,7 +706830,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -706140,7 +706857,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -706188,7 +706904,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -706298,7 +707013,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -706667,13 +707381,15 @@ 0, 0, 0, - 2, 0, 0, 0, 2, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -706689,48 +707405,46 @@ }, { "session": { - "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware", - "sourceId": "W3DKPQ", - "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware", - "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.", - "track": "Core Protocol", + "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations", + "sourceId": "MVJFDX", + "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations", + "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.", + "track": "Cypherpunk & Privacy", "type": "Workshop", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Product", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Node Operation", - "Low-Power Hardware" + "Legal" ], "tags": [ - "Layer 1", - "Decentralization Improvements", - "Layer 2s", - "Decentralization", - "hardware", - "low-power", - "Decentralization", - "Decentralization Improvements", - "Layer 1", - "Layer 2s" + "Frameworks", + "Privacy", + "Censorship Resistance", + "legal", + "Censorship Resistance", + "Frameworks", + "Privacy" ], "language": "en", "speakers": [ - "diego-losada", - "fernando-collado" + "fatemeh-fannizadeh", + "andre-omietanski", + "amal-ibraymi" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731477600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ" + "slot_start": 1731576600000, + "slot_end": 1731582000000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA" }, "vector": [ 0, 0, 0, 0, + 0, 6, 0, 0, @@ -707023,7 +707737,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -707251,6 +707964,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -707336,6 +708051,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -707472,7 +708188,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -707481,7 +708196,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -707532,7 +708246,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -707568,7 +708281,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -707576,6 +708288,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -707586,6 +708300,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -707616,6 +708331,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -707645,7 +708361,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -707958,8 +708673,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -708032,13 +708747,15 @@ 0, 2, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -708050,39 +708767,38 @@ }, { "session": { - "id": "sybil-proof-mechanisms", - "sourceId": "7QENZH", - "title": "Sybil-Proof Mechanisms", - "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.", + "id": "superliquid-mechanisms-for-decentralized-stablecoins", + "sourceId": "SLNQ8K", + "title": "Superliquid Mechanisms for Decentralized Stablecoins", + "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.", "track": "Cryptoeconomics", - "type": "Lightning Talk", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "APS" + "Stablecoins", + "DeFi" ], "tags": [ - "PBS", - "Mechanism design", - "Game Theory", - "MEV", - "apps", - "Game Theory", "Mechanism design", - "MEV", - "PBS" + "Economics", + "AMMs", + "defi", + "AMMs", + "Economics", + "Mechanism design" ], "language": "en", "speakers": [ - "christoph-schlegel" + "ariah-klages-mundt" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731487200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU" }, "vector": [ 0, @@ -708284,7 +709000,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -708579,6 +709294,12 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -708826,13 +709547,56 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 6, - 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -708973,6 +709737,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -709317,7 +710087,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -709337,9 +710106,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -709352,10 +710123,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware", + "sourceId": "W3DKPQ", + "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware", + "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.", + "track": "Core Protocol", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Node Operation", + "Low-Power Hardware" + ], + "tags": [ + "Layer 1", + "Decentralization Improvements", + "Layer 2s", + "Decentralization", + "hardware", + "low-power", + "Decentralization", + "Decentralization Improvements", + "Layer 1", + "Layer 2s" + ], + "language": "en", + "speakers": [ + "diego-losada", + "fernando-collado" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731477600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -709386,12 +710201,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -709403,32 +710216,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "synthetic-melodies-a-digital-soundscape", - "sourceId": "EZ3EVX", - "title": "Synthetic Melodies: A Digital Soundscape", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731405600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg" - }, - "vector": [ 0, 0, 0, @@ -709438,7 +710225,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -709677,6 +710463,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -709991,6 +710778,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -710127,6 +710915,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -710135,6 +710924,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -710185,6 +710975,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -710220,6 +711011,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -710296,6 +711088,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -710608,6 +711401,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -710679,7 +711473,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -710692,8 +711488,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "sybil-proof-mechanisms", + "sourceId": "7QENZH", + "title": "Sybil-Proof Mechanisms", + "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "APS" + ], + "tags": [ + "PBS", + "Mechanism design", + "Game Theory", + "MEV", + "apps", + "Game Theory", + "Mechanism design", + "MEV", + "PBS" + ], + "language": "en", + "speakers": [ + "christoph-schlegel" + ], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731487200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -710731,10 +711568,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -710747,32 +711582,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "synto-nikka", - "sourceId": "ZBSJDY", - "title": "Synto Nikka", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731497400000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic" - }, - "vector": [ 0, 0, 0, @@ -710782,7 +711591,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -710920,6 +711728,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -711464,10 +712273,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -711498,6 +712310,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -711951,6 +712764,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -712019,10 +712833,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -712034,6 +712850,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "synthetic-melodies-a-digital-soundscape", + "sourceId": "EZ3EVX", + "title": "Synthetic Melodies: A Digital Soundscape", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731402000000, + "slot_end": 1731405600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -712075,10 +712935,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -712091,54 +712949,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance", - "sourceId": "QKMVPC", - "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance", - "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Local/SEA", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Population Decline", - "Local Government", - "NFT", - "Public Service" - ], - "tags": [ - "Public good", - "Local Impact", - "service", - "public", - "Autonomous World", - "Local Impact", - "Public good" - ], - "language": "en", - "speakers": [ - "atsushi-hayashiatsu" - ], - "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731574200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -712741,7 +713557,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -712980,8 +713795,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -713116,7 +713929,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -713307,69 +714119,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, - 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, @@ -713433,6 +714182,7 @@ 0, 0, 0, + 2, 0, 0, 2, @@ -713448,55 +714198,37 @@ 0, 0, 0, - 0, - 2, 0 ] }, { "session": { - "id": "tales-from-interop", - "sourceId": "UQPDPQ", - "title": "Tales from interop", - "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", + "id": "synto-nikka", + "sourceId": "ZBSJDY", + "title": "Synto Nikka", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Core Protocol", - "Security", - "Testing", - "devops", - "Core Protocol", - "Security", - "Testing" - ], - "keywords": [ - "DevOps" - ], - "duration": 1433, + "keywords": [], + "tags": [], "language": "en", - "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d", - "sources_youtubeId": "NHsi-lyOEUA", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673326163a168eb53561c36a.vtt", - "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?", + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0", - "resources_slides": null, - "speakers": [ - "parithosh-jayanthi" - ] + "slot_start": 1731492000000, + "slot_end": 1731497400000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic" }, "vector": [ + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -714107,7 +714839,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -714236,7 +714967,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -714255,7 +714985,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -714479,7 +715208,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -714730,7 +715458,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -714798,10 +715525,14 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -714820,37 +715551,40 @@ }, { "session": { - "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem", - "sourceId": "U7SNLQ", - "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem", - "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.", - "track": "Cypherpunk & Privacy", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": true, + "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance", + "sourceId": "QKMVPC", + "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance", + "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Local/SEA", + "featured": false, "doNotRecord": false, "keywords": [ - "Ethereum", - "Core", - "Development;", - "Social", - "Layer;", - "Governance;", - "Values" + "Population Decline", + "Local Government", + "NFT", + "Public Service" ], "tags": [ - "value" + "Public good", + "Local Impact", + "service", + "public", + "Autonomous World", + "Local Impact", + "Public good" ], "language": "en", "speakers": [ - "ann-brody" + "atsushi-hayashiatsu" ], "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4" + "slot_start": 1731573600000, + "slot_end": 1731574200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E" }, "vector": [ 0, @@ -714858,6 +715592,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -715464,6 +716199,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -715703,6 +716439,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -715837,6 +716575,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -715966,7 +716705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -716028,6 +716766,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -716056,6 +716795,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -716160,9 +716900,6 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -716171,59 +716908,61 @@ 0, 0, 0, + 2, 0 ] }, { "session": { - "id": "the-10-most-common-vulnerabilities-found-in-audit-contests", - "sourceId": "LYFXZN", - "title": "The 10 Most Common Vulnerabilities Found in Audit Contests", - "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed", - "track": "Security", - "type": "Lightning Talk", + "id": "tales-from-interop", + "sourceId": "UQPDPQ", + "title": "Tales from interop", + "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.", + "track": "Core Protocol", + "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, "tags": [ + "Core Protocol", "Security", - "Auditing", - "audit", - "contest", - "Auditing", - "Security" + "Testing", + "devops", + "Core Protocol", + "Security", + "Testing" ], "keywords": [ - "Vulnerabilities;", - "Audit", - "Contests" + "DevOps" ], - "duration": 595, + "duration": 1433, "language": "en", - "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0", - "sources_youtubeId": "MT7mYhwgksI", + "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d", + "sources_youtubeId": "NHsi-lyOEUA", "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/673326163a168eb53561c36a.vtt", + "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?", "eventId": "devcon-7", - "slot_start": 1731408000000, - "slot_end": 1731408600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII", + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0", "resources_slides": null, "speakers": [ - "jack-sanford" + "parithosh-jayanthi" ] }, "vector": [ - 6, 0, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -716958,6 +717697,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -716977,6 +717718,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -717110,7 +717856,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -717197,6 +717942,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -717234,19 +717987,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -717520,8 +718260,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -717537,45 +718277,43 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-age-of-account-abstraction-opportunities-and-challenges", - "sourceId": "EPN9S7", - "title": "The Age of Account Abstraction: Opportunities and Challenges", - "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.", - "track": "Usability", - "type": "Lightning Talk", + "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem", + "sourceId": "U7SNLQ", + "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem", + "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.", + "track": "Cypherpunk & Privacy", + "type": "Talk", "expertise": "Intermediate", - "audience": "Business", - "featured": false, + "audience": "Developer", + "featured": true, "doNotRecord": false, "keywords": [ - "Protocol competition", - "User growth", - "Layer specialisation" + "Ethereum", + "Core", + "Development;", + "Social", + "Layer;", + "Governance;", + "Values" ], "tags": [ - "Layer 2s", - "Account Abstraction", - "Intents", - "specialisation", - "layer", - "Account Abstraction", - "Intents", - "Layer 2s" + "value" ], "language": "en", "speakers": [ - "daniel-yanev" + "ann-brody" ], "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731552900000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU" + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4" }, "vector": [ 0, @@ -717583,10 +718321,12 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -718368,11 +719108,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -718383,7 +719121,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -718676,7 +719413,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -718697,6 +719433,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -718813,7 +719551,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -718879,12 +719616,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 2, 0, @@ -718896,47 +719637,58 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-age-of-aggregation", - "sourceId": "VVTWM7", - "title": "The Age Of AGGREGATION", - "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience", - "track": "Layer 2", - "type": "Talk", + "id": "the-10-most-common-vulnerabilities-found-in-audit-contests", + "sourceId": "LYFXZN", + "title": "The 10 Most Common Vulnerabilities Found in Audit Contests", + "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed", + "track": "Security", + "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Product", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Blockchain optimization", - "performance enhancement", - "scalability" - ], "tags": [ - "Protocol Design", - "Scalability", - "Token bridging", - "User Experience", - "Protocol Design", - "Token bridging", - "User Experience" + "Security", + "Auditing", + "audit", + "contest", + "Auditing", + "Security" ], - "language": "en", - "speakers": [ - "sandeep-nailwal", - "marc-boiron" + "keywords": [ + "Vulnerabilities;", + "Audit", + "Contests" ], + "duration": 595, + "language": "en", + "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0", + "sources_youtubeId": "MT7mYhwgksI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731646800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA" + "slot_start": 1731408000000, + "slot_end": 1731408600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII", + "resources_slides": null, + "speakers": [ + "jack-sanford" + ] }, "vector": [ + 6, + 0, + 0, 0, 0, 0, @@ -718944,7 +719696,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -719551,7 +720302,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -719679,6 +720429,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -719692,7 +720443,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -719722,7 +720472,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719816,7 +720565,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719833,6 +720581,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -719881,7 +720630,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -719957,6 +720705,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -720175,6 +720924,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -720238,10 +720988,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -720255,54 +721005,48 @@ 0, 0, 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities", - "sourceId": "GSZKVK", - "title": "The Blind Man's Elephant: a product vision towards private identities", - "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.", - "track": "Applied Cryptography", + "id": "the-age-of-account-abstraction-opportunities-and-challenges", + "sourceId": "EPN9S7", + "title": "The Age of Account Abstraction: Opportunities and Challenges", + "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.", + "track": "Usability", "type": "Lightning Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Business", "featured": false, "doNotRecord": false, - "tags": [ - "Privacy", - "Identity", - "ZKP", - "Use Cases", - "selective", - "disclosure", - "Identity", - "Privacy", - "Use Cases", - "ZKP" - ], "keywords": [ - "Selective-disclosure" + "Protocol competition", + "User growth", + "Layer specialisation" + ], + "tags": [ + "Layer 2s", + "Account Abstraction", + "Intents", + "specialisation", + "layer", + "Account Abstraction", + "Intents", + "Layer 2s" ], - "duration": 706, "language": "en", - "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9", - "sources_youtubeId": "-BESF3MUM20", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "daniel-yanev" + ], "eventId": "devcon-7", - "slot_start": 1731395400000, - "slot_end": 1731396000000, + "slot_start": 1731552300000, + "slot_end": 1731552900000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA", - "resources_slides": null, - "speakers": [ - "andy" - ] + "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU" }, "vector": [ 0, @@ -720313,9 +721057,10 @@ 0, 0, 0, + 6, + 0, 0, 0, - 6, 0, 0, 0, @@ -721093,6 +721838,15 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, 2, 0, 0, @@ -721104,6 +721858,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -721119,11 +721883,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -721161,7 +721923,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -721390,6 +722151,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -721519,6 +722288,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -721541,35 +722318,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -721610,10 +722358,10 @@ 0, 0, 0, - 2, 0, 0, 0, + 2, 0, 0, 0, @@ -721628,45 +722376,40 @@ }, { "session": { - "id": "the-chain-abstraction-master-plan", - "sourceId": "DCSCA7", - "title": "The Chain Abstraction Master Plan", - "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.", - "track": "Usability", + "id": "the-age-of-aggregation", + "sourceId": "VVTWM7", + "title": "The Age Of AGGREGATION", + "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience", + "track": "Layer 2", "type": "Talk", "expertise": "Intermediate", "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Chain Abstraction", - "OneBalance", - "Resource Locks" + "Blockchain optimization", + "performance enhancement", + "scalability" ], "tags": [ - "Account Abstraction", - "Cross-L2", - "Developer Infrastructure", - "DevEx", - "Ethereum Roadmap", - "Gas", - "Intents", - "MEV", - "Paymaster", - "Rollups", + "Protocol Design", + "Scalability", + "Token bridging", + "User Experience", + "Protocol Design", "Token bridging", - "Transaction fees mechanisms", "User Experience" ], "language": "en", "speakers": [ - "stephane-gosselin" + "sandeep-nailwal", + "marc-boiron" ], "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731577800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0" + "slot_start": 1731645000000, + "slot_end": 1731646800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA" }, "vector": [ 0, @@ -721676,7 +722419,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -722286,6 +723028,9 @@ 0, 0, 0, + 0, + 0, + 6, 6, 0, 0, @@ -722410,7 +723155,9 @@ 0, 0, 0, - 6, + 0, + 0, + 0, 0, 0, 0, @@ -722438,7 +723185,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -722448,7 +723194,12 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 2, 0, @@ -722459,11 +723210,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -722547,6 +723295,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -722602,7 +723351,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -722610,7 +723358,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -722638,7 +723385,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -722839,7 +723585,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -722992,35 +723739,49 @@ }, { "session": { - "id": "the-chain-mail-gaze", - "sourceId": "73SKE9", - "title": "The Chain Mail Gaze", - "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.", - "track": "Coordination", + "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities", + "sourceId": "GSZKVK", + "title": "The Blind Man's Elephant: a product vision towards private identities", + "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.", + "track": "Applied Cryptography", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "decolonial" - ], "tags": [ - "Governance", - "Network State", - "decolonial", - "Governance", - "Network State" + "Privacy", + "Identity", + "ZKP", + "Use Cases", + "selective", + "disclosure", + "Identity", + "Privacy", + "Use Cases", + "ZKP" ], - "language": "en", - "speakers": [ - "wassim-z-alsindi" + "keywords": [ + "Selective-disclosure" ], + "duration": 706, + "language": "en", + "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9", + "sources_youtubeId": "-BESF3MUM20", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731409800000, - "slot_end": 1731410400000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk" + "slot_start": 1731395400000, + "slot_end": 1731396000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA", + "resources_slides": null, + "speakers": [ + "andy" + ] }, "vector": [ 0, @@ -723033,7 +723794,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -723641,10 +724401,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -723809,7 +724569,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -723817,6 +724576,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -723842,9 +724602,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -723858,7 +724620,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -723883,6 +724644,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -724261,8 +725023,9 @@ 0, 0, 0, - 2, 0, + 2, + 2, 0, 0, 0, @@ -724329,6 +725092,7 @@ 2, 0, 0, + 0, 2, 0, 0, @@ -724341,57 +725105,53 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists", - "sourceId": "TPLHFG", - "title": "The challenges of leaving laboratory outbreaks to scientists", - "description": "NA", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Expert", - "audience": "Academic", + "id": "the-chain-abstraction-master-plan", + "sourceId": "DCSCA7", + "title": "The Chain Abstraction Master Plan", + "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Chain Abstraction", + "OneBalance", + "Resource Locks" + ], + "tags": [ + "Account Abstraction", + "Cross-L2", + "Developer Infrastructure", + "DevEx", + "Ethereum Roadmap", + "Gas", + "Intents", + "MEV", + "Paymaster", + "Rollups", + "Token bridging", + "Transaction fees mechanisms", + "User Experience" + ], "language": "en", "speakers": [ - "alina-chan" + "stephane-gosselin" ], "eventId": "devcon-7", - "slot_start": 1731567900000, - "slot_end": 1731568500000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ" + "slot_start": 1731576600000, + "slot_end": 1731577800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0" }, "vector": [ - 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, @@ -724400,6 +725160,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -724988,7 +725749,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -725013,6 +725773,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -725136,6 +725897,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -725149,6 +725911,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -725162,6 +725925,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725171,7 +725935,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -725180,8 +725946,11 @@ 0, 0, 0, + 2, 0, 0, + 2, + 2, 0, 0, 0, @@ -725320,6 +726089,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725327,8 +726097,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -725353,6 +726125,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -725553,6 +726326,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -725673,7 +726448,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -725687,49 +726461,53 @@ 0, 0, 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-combination-of-zkp-mpc-fhe", - "sourceId": "XPLVT8", - "title": "The combination of ZKP +/- MPC +/- FHE", - "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.", - "track": "Applied Cryptography", + "id": "the-chain-mail-gaze", + "sourceId": "73SKE9", + "title": "The Chain Mail Gaze", + "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.", + "track": "Coordination", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, - "tags": [ - "ZKP", - "MPC", - "fhe", - "MPC", - "ZKP" - ], "keywords": [ - "FHE" + "decolonial" + ], + "tags": [ + "Governance", + "Network State", + "decolonial", + "Governance", + "Network State" ], - "duration": 521, "language": "en", - "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18", - "sources_youtubeId": "Tq7CVqDE_P4", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt", - "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.", - "eventId": "devcon-7", - "slot_start": 1731390000000, - "slot_end": 1731390600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk", - "resources_slides": null, "speakers": [ - "giacomo" - ] + "wassim-z-alsindi" + ], + "eventId": "devcon-7", + "slot_start": 1731409800000, + "slot_end": 1731410400000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk" }, "vector": [ 0, @@ -725742,6 +726520,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -726352,6 +727131,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -726520,6 +727300,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -726546,7 +727328,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -726560,7 +727341,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -726569,6 +727349,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -726834,7 +727615,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -726972,6 +727752,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -727035,8 +727816,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 2, @@ -727050,32 +727831,33 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-dacc-vision-balancing-progress-and-protection", - "sourceId": "AA8SRQ", - "title": "The d/acc Vision: Balancing Progress and Protection", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists", + "sourceId": "TPLHFG", + "title": "The challenges of leaving laboratory outbreaks to scientists", + "description": "NA", "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "expertise": "Expert", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [], "tags": [], "language": "en", "speakers": [ - "vitalik-buterin" + "alina-chan" ], "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731553800000, + "slot_start": 1731567900000, + "slot_end": 1731568500000, "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo" + "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ" }, "vector": [ 0, @@ -727272,7 +728054,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -727702,6 +728483,11 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -728380,7 +729166,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -728393,6 +729178,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -728401,36 +729187,44 @@ }, { "session": { - "id": "the-daos-of-the-east", - "sourceId": "BUKGLV", - "title": "The DAOs of the East", - "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.", - "track": "Coordination", - "type": "Talk", + "id": "the-combination-of-zkp-mpc-fhe", + "sourceId": "XPLVT8", + "title": "The combination of ZKP +/- MPC +/- FHE", + "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.", + "track": "Applied Cryptography", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Developer", "featured": false, "doNotRecord": false, - "keywords": [ - "Asia" - ], "tags": [ - "DAO", - "Collective Intelligence", - "Regulation", - "asia", - "Collective Intelligence", - "DAO" + "ZKP", + "MPC", + "fhe", + "MPC", + "ZKP" ], - "language": "en", - "speakers": [ - "joshua-tan" + "keywords": [ + "FHE" ], + "duration": 521, + "language": "en", + "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18", + "sources_youtubeId": "Tq7CVqDE_P4", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt", + "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.", "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y" + "slot_start": 1731390000000, + "slot_end": 1731390600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk", + "resources_slides": null, + "speakers": [ + "giacomo" + ] }, "vector": [ 0, @@ -728443,7 +729237,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -729054,6 +729847,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 6, 0, 0, @@ -729206,7 +730003,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -729249,6 +730045,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -729262,6 +730059,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -729273,13 +730072,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -729536,6 +730333,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -729628,7 +730427,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -729740,10 +730538,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -729756,48 +730554,37 @@ }, { "session": { - "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral", - "sourceId": "C7ZFH3", - "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral", - "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "the-dacc-vision-balancing-progress-and-protection", + "sourceId": "AA8SRQ", + "title": "The d/acc Vision: Balancing Progress and Protection", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Interactive", - "fraud", - "proofs" - ], - "tags": [ - "Optimistic rollups", - "fraud", - "proof", - "Optimistic", - "rollups" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "gabriel-coutinho-de-paula", - "augusto-teixeira" + "vitalik-buterin" ], "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s" + "slot_start": 1731553200000, + "slot_end": 1731553800000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -729985,6 +730772,39 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -730412,8 +731232,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -730597,7 +731415,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -730755,7 +731572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -730874,7 +731690,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -731029,30 +731844,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -731092,11 +731883,11 @@ 0, 0, 0, + 2, 0, 0, 2, 0, - 2, 0, 0, 0, @@ -731113,39 +731904,36 @@ }, { "session": { - "id": "the-end-of-self-custodial-wallets", - "sourceId": "KDUNLM", - "title": "The end of self-custodial wallets", - "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", + "id": "the-daos-of-the-east", + "sourceId": "BUKGLV", + "title": "The DAOs of the East", + "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", - "audience": "Business", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Self custodial", - "FATF", - "wallet" + "Asia" ], "tags": [ - "Free Speech", - "Censorship Resistance", + "DAO", + "Collective Intelligence", "Regulation", - "fatf", - "Censorship Resistance", - "Free Speech", - "Regulation" + "asia", + "Collective Intelligence", + "DAO" ], "language": "en", "speakers": [ - "mikko-ohtamaa" + "joshua-tan" ], "eventId": "devcon-7", - "slot_start": 1731647400000, - "slot_end": 1731648000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg" + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y" }, "vector": [ 0, @@ -731153,13 +731941,14 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -731914,7 +732703,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -731925,6 +732713,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -731990,6 +732780,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -732035,7 +732827,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -732344,6 +733135,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -732389,7 +733182,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -732456,9 +733248,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 0, 0, @@ -732471,35 +733263,38 @@ }, { "session": { - "id": "the-evolution-of-zk-from-1985-2013", - "sourceId": "FGXMGH", - "title": "The Evolution of ZK from 1985-2013", - "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.", - "track": "Applied Cryptography", + "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral", + "sourceId": "C7ZFH3", + "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral", + "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.", + "track": "Layer 2", "type": "Talk", "expertise": "Expert", - "audience": "Developer", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "history" + "Interactive", + "fraud", + "proofs" ], "tags": [ - "Zero-Knowledge", - "Cryptography", - "history", - "Cryptography", - "Zero-Knowledge" + "Optimistic rollups", + "fraud", + "proof", + "Optimistic", + "rollups" ], "language": "en", "speakers": [ - "vanishree-rao" + "gabriel-coutinho-de-paula", + "augusto-teixeira" ], "eventId": "devcon-7", - "slot_start": 1731656400000, - "slot_end": 1731658200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE" + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s" }, "vector": [ 0, @@ -732509,11 +733304,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -732981,7 +733775,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -733130,6 +733923,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -733253,8 +734048,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -733315,6 +734108,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -733472,6 +734266,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -733590,6 +734385,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -733745,6 +734541,7 @@ 0, 0, 2, + 2, 0, 0, 0, @@ -733806,11 +734603,13 @@ 0, 0, 0, - 2, 0, 0, 2, 0, + 2, + 0, + 0, 0, 0, 0, @@ -733825,38 +734624,44 @@ }, { "session": { - "id": "the-fixed-rate-flywheel", - "sourceId": "WYWLXV", - "title": "The Fixed Rate Flywheel", - "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.", - "track": "Cryptoeconomics", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "the-end-of-self-custodial-wallets", + "sourceId": "KDUNLM", + "title": "The end of self-custodial wallets", + "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", "featured": false, "doNotRecord": false, "keywords": [ - "DeFi", - "Fixed Rates" + "Self custodial", + "FATF", + "wallet" ], "tags": [ - "fixed", - "rate" + "Free Speech", + "Censorship Resistance", + "Regulation", + "fatf", + "Censorship Resistance", + "Free Speech", + "Regulation" ], "language": "en", "speakers": [ - "alex-towle", - "merlin-egalite", - "lucas-manuel", - "violet-vienhage" + "mikko-ohtamaa" ], "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731495000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg" + "slot_start": 1731647400000, + "slot_end": 1731648000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg" }, "vector": [ + 0, + 0, + 0, 0, 0, 6, @@ -734483,10 +735288,6 @@ 0, 0, 6, - 6, - 6, - 6, - 0, 0, 0, 0, @@ -734628,6 +735429,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -734707,6 +735509,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -734747,6 +735550,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -735101,7 +735905,6 @@ 0, 0, 2, - 2, 0, 0, 0, @@ -735158,7 +735961,8 @@ 0, 0, 0, - 2, + 0, + 0, 0, 0, 0, @@ -735167,6 +735971,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -735180,61 +735986,37 @@ }, { "session": { - "id": "the-franklin-fallacy-why-we-misjudge-new-technologies", - "sourceId": "W7MVPA", - "title": "The Franklin Fallacy: Why We Misjudge New Technologies", - "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk delves into the psychology of this fallacy.", - "track": "Real World Ethereum", + "id": "the-evolution-of-zk-from-1985-2013", + "sourceId": "FGXMGH", + "title": "The Evolution of ZK from 1985-2013", + "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Beginner", - "audience": "Academic", + "expertise": "Expert", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Technological", - "Acceptance" + "history" ], "tags": [ - "e/acc", - "Marketing" + "Zero-Knowledge", + "Cryptography", + "history", + "Cryptography", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "louis-anslow" + "vanishree-rao" ], "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ" + "slot_start": 1731656400000, + "slot_end": 1731658200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE" }, "vector": [ - 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, @@ -735245,6 +736027,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -735715,6 +736498,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -735838,7 +736622,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -735989,6 +736772,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -736104,7 +736889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -736238,7 +737022,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -736480,6 +737263,26 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -736512,7 +737315,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -736526,49 +737328,61 @@ 2, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0 ] }, { "session": { - "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai", - "sourceId": "EK8T9X", - "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI", - "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", + "id": "the-fixed-rate-flywheel", + "sourceId": "WYWLXV", + "title": "The Fixed Rate Flywheel", + "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.", + "track": "Cryptoeconomics", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "AI" + "DeFi", + "Fixed Rates" ], "tags": [ - "Censorship Resistance", - "Permissionless", - "Privacy" + "fixed", + "rate" ], "language": "en", "speakers": [ - "teana-baker-taylor" + "alex-towle", + "merlin-egalite", + "lucas-manuel", + "violet-vienhage" ], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731564600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s" + "slot_start": 1731491400000, + "slot_end": 1731495000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg" }, "vector": [ 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -737192,6 +738006,9 @@ 0, 0, 6, + 6, + 6, + 6, 0, 0, 0, @@ -737417,7 +738234,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -737448,7 +738264,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -737492,7 +738307,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -737809,6 +738623,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -737868,9 +738685,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -737884,44 +738703,41 @@ }, { "session": { - "id": "the-future-of-eof-layer-1-layer-2-and-beyond", - "sourceId": "9EBQ3H", - "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!", - "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.", - "track": "Core Protocol", + "id": "the-franklin-fallacy-why-we-misjudge-new-technologies", + "sourceId": "W7MVPA", + "title": "The Franklin Fallacy: Why We Misjudge New Technologies", + "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk delves into the psychology of this fallacy.", + "track": "Real World Ethereum", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Academic", "featured": false, "doNotRecord": false, "keywords": [ - "EOF", - "EVM" + "Technological", + "Acceptance" ], "tags": [ - "Layer 1", - "EVM-equivalent", - "Politics", - "EVM", - "EVM-equivalent", - "Layer 1", - "Politics" + "e/acc", + "Marketing" ], "language": "en", "speakers": [ - "danno-ferrin" + "louis-anslow" ], "eventId": "devcon-7", - "slot_start": 1731563400000, - "slot_end": 1731565200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI" + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ" }, "vector": [ 0, 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -738254,7 +739070,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -738550,6 +739365,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -738672,7 +739489,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -738815,6 +739631,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -738866,7 +739683,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -738949,6 +739765,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -738981,7 +739800,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -738992,7 +739810,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -739219,7 +740036,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -739234,6 +740050,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0 @@ -739241,35 +740059,33 @@ }, { "session": { - "id": "the-future-of-layer-2-research-development-and-next-gen-technologies", - "sourceId": "PJQQSR", - "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies", - "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", + "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai", + "sourceId": "EK8T9X", + "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI", + "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Arbitrum" + "AI" ], "tags": [ - "Layer 2s", - "Scalability", - "arbitrum", - "Layer 2s", - "Scalability" + "Censorship Resistance", + "Permissionless", + "Privacy" ], "language": "en", "speakers": [ - "ed-felten" + "teana-baker-taylor" ], "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k" + "slot_start": 1731564000000, + "slot_end": 1731564600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s" }, "vector": [ 0, @@ -739278,7 +740094,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -739903,11 +740718,12 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -740077,7 +740893,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -740133,6 +740948,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -740151,7 +740967,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -740164,6 +740979,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -740207,6 +741023,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -740517,7 +741334,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -740573,13 +741389,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -740590,40 +741406,49 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-future-of-light-clients", - "sourceId": "UL8U8B", - "title": "The Future of Light Clients", - "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.", - "track": "Layer 2", + "id": "the-future-of-eof-layer-1-layer-2-and-beyond", + "sourceId": "9EBQ3H", + "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!", + "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.", + "track": "Core Protocol", "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [], + "keywords": [ + "EOF", + "EVM" + ], "tags": [ - "Layer 2s", - "Light Clients" + "Layer 1", + "EVM-equivalent", + "Politics", + "EVM", + "EVM-equivalent", + "Layer 1", + "Politics" ], "language": "en", "speakers": [ - "noah-citron" + "danno-ferrin" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8" + "slot_start": 1731563400000, + "slot_end": 1731565200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI" }, "vector": [ - 0, - 0, - 0, 0, 0, 0, @@ -740962,6 +741787,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -741253,29 +742079,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -741380,7 +742183,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -741405,6 +742207,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -741426,7 +742229,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -741599,6 +742401,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -741713,6 +742516,32 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -741927,6 +742756,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -741939,38 +742770,41 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-future-of-web3-grants-learnings-from-studying-30-programs", - "sourceId": "F9YCZY", - "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs", - "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "the-future-of-layer-2-research-development-and-next-gen-technologies", + "sourceId": "PJQQSR", + "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies", + "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", "featured": false, "doNotRecord": false, "keywords": [ - "Grant", - "Allocation", - "Capital" + "Arbitrum" ], "tags": [ - "capital" + "Layer 2s", + "Scalability", + "arbitrum", + "Layer 2s", + "Scalability" ], "language": "en", "speakers": [ - "eugene-leventhal" + "ed-felten" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731642000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg" + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k" }, "vector": [ 0, @@ -741980,11 +742814,12 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -742606,8 +743441,8 @@ 0, 0, 0, - 6, 0, + 6, 0, 0, 0, @@ -742781,6 +743616,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -742854,6 +743690,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -743275,7 +744112,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -743283,12 +744119,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, + 0, + 0, 0, 0, 0 @@ -743296,41 +744134,40 @@ }, { "session": { - "id": "the-grand-vision-of-futarchy", - "sourceId": "3UX8GZ", - "title": "The Grand Vision of Futarchy", - "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "id": "the-future-of-light-clients", + "sourceId": "UL8U8B", + "title": "The Future of Light Clients", + "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [], "tags": [ - "Economics", - "Free Speech", - "Futarchy" + "Layer 2s", + "Light Clients" ], "language": "en", "speakers": [ - "robin-hanson" + "noah-citron" ], "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731563100000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE" + "slot_start": 1731493800000, + "slot_end": 1731495600000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8" }, "vector": [ 0, - 6, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -743588,7 +744425,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -743960,6 +744796,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -744085,19 +744923,17 @@ 0, 0, 0, + 2, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -744133,6 +744969,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -744626,12 +745463,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 2, 0, 2, 0, @@ -744641,57 +745478,42 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-history-and-philosophy-of-cypherpunk", - "sourceId": "8JVYCQ", - "title": "The History and Philosophy of Cypherpunk", - "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.", - "track": "Cypherpunk & Privacy", - "type": "Talk", + "id": "the-future-of-web3-grants-learnings-from-studying-30-programs", + "sourceId": "F9YCZY", + "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs", + "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.", + "track": "Coordination", + "type": "Lightning Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, - "tags": [ - "Anonymity", - "Censorship Resistance", - "Digital Sovereignty", - "cypherpunk", - "mixnet", - "cryptoanarchy", - "Anonymity", - "Politics", - "Values" - ], "keywords": [ - "mixnets", - "cypherpunk", - "cryptoanarchist" + "Grant", + "Allocation", + "Capital" + ], + "tags": [ + "capital" ], - "duration": 1555, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "prXQJSp_H8A", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt", - "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo", - "resources_slides": null, "speakers": [ - "harry-halpin", - "iness-ben-guirat", - "max-hampshire" - ] + "eugene-leventhal" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731642000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg" }, "vector": [ 0, @@ -744699,13 +745521,17 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -745058,7 +745884,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -745328,7 +746153,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -745459,7 +746283,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745483,7 +746306,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745545,7 +746367,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745581,7 +746402,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745768,7 +746588,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745815,7 +746634,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -745941,7 +746759,13 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 2, 0, 0, @@ -745997,6 +746821,8 @@ 0, 0, 0, + 0, + 0, 2, 0, 0, @@ -746017,49 +746843,41 @@ }, { "session": { - "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets", - "sourceId": "TV3QRD", - "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets", - "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.", - "track": "Real World Ethereum", - "type": "Talk", + "id": "the-grand-vision-of-futarchy", + "sourceId": "3UX8GZ", + "title": "The Grand Vision of Futarchy", + "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "Emerging Markets", - "Africa", - "Latin America" - ], + "keywords": [], "tags": [ - "Use Cases", - "RWA", - "Ethereum for Good", - "latin", - "america", - "Ethereum for Good", - "RWA", - "Use Cases" + "Economics", + "Free Speech", + "Futarchy" ], "language": "en", "speakers": [ - "timothy-asiimwe" + "robin-hanson" ], "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ" + "slot_start": 1731562200000, + "slot_end": 1731563100000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE" }, "vector": [ + 0, + 6, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -746318,6 +747136,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -746689,7 +747508,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -746822,12 +747640,15 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -746871,7 +747692,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -746918,7 +747738,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -746946,7 +747765,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -747302,8 +748120,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -747356,7 +748172,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -747369,6 +748184,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0 @@ -747376,45 +748197,60 @@ }, { "session": { - "id": "the-long-con-pig-butchering-drainers-and-job-scams", - "sourceId": "STMCNZ", - "title": "The Long Con: Pig Butchering, Drainers, and Job Scams", - "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.", - "track": "Security", + "id": "the-history-and-philosophy-of-cypherpunk", + "sourceId": "8JVYCQ", + "title": "The History and Philosophy of Cypherpunk", + "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.", + "track": "Cypherpunk & Privacy", "type": "Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, - "keywords": [ - "threat", - "intelligence" - ], "tags": [ - "Security", - "Custody", - "threat", - "intelligence", - "Custody", - "Security" + "Anonymity", + "Censorship Resistance", + "Digital Sovereignty", + "cypherpunk", + "mixnet", + "cryptoanarchy", + "Anonymity", + "Politics", + "Values" ], - "language": "en", - "speakers": [ - "luker" + "keywords": [ + "mixnets", + "cypherpunk", + "cryptoanarchist" ], + "duration": 1555, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "prXQJSp_H8A", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt", + "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big", "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk" + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo", + "resources_slides": null, + "speakers": [ + "max-hampshire", + "harry-halpin", + "iness-ben-guirat" + ] }, "vector": [ - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -747775,6 +748611,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -748047,6 +748884,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -748148,9 +748986,6 @@ 0, 0, 0, - 6, - 0, - 0, 0, 0, 0, @@ -748179,6 +749014,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748202,6 +749038,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748263,6 +749100,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748298,6 +749136,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748402,8 +749241,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -748486,6 +749323,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748532,6 +749370,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -748628,7 +749467,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -748658,6 +749496,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -748732,41 +749572,49 @@ }, { "session": { - "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging", - "sourceId": "V9BA8B", - "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", - "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", + "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets", + "sourceId": "TV3QRD", + "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets", + "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, "keywords": [ - "Longevity" + "Emerging Markets", + "Africa", + "Latin America" ], "tags": [ - "DeSci", - "e/acc" + "Use Cases", + "RWA", + "Ethereum for Good", + "latin", + "america", + "Ethereum for Good", + "RWA", + "Use Cases" ], "language": "en", "speakers": [ - "nathan-cheng" + "timothy-asiimwe" ], "eventId": "devcon-7", - "slot_start": 1731557580000, - "slot_end": 1731558000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso" + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ" }, "vector": [ 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -749398,9 +750246,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -749582,6 +750430,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -749628,12 +750477,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -749655,8 +750504,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -750012,6 +750861,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -750062,7 +750913,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -750071,6 +750921,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -750083,43 +750935,43 @@ }, { "session": { - "id": "the-next-700-evm-languages", - "sourceId": "QE7RWH", - "title": "The Next 700 EVM Languages", - "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.", - "track": "Developer Experience", + "id": "the-long-con-pig-butchering-drainers-and-job-scams", + "sourceId": "STMCNZ", + "title": "The Long Con: Pig Butchering, Drainers, and Job Scams", + "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.", + "track": "Security", "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "programming languages", - "formal verification", - "smart contracts" + "threat", + "intelligence" ], "tags": [ - "Languages", - "Formal Verification", - "smart", - "contracts" + "Security", + "Custody", + "threat", + "intelligence", + "Custody", + "Security" ], "language": "en", "speakers": [ - "francisco-giordano" + "luker" ], "eventId": "devcon-7", - "slot_start": 1731580200000, - "slot_end": 1731582000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y" + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk" }, "vector": [ + 6, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -750754,10 +751606,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, 0, 0, 0, @@ -750859,6 +751711,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -750951,7 +751804,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -751053,7 +751905,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -751340,6 +752191,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -751416,7 +752272,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -751427,6 +752282,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -751438,48 +752295,37 @@ }, { "session": { - "id": "the-next-era-sequencing-and-its-real-impact-on-app-users", - "sourceId": "9M78AK", - "title": "The Next Era: Sequencing and Its Real Impact on App Users", - "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", + "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging", + "sourceId": "V9BA8B", + "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", + "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Layer 2s", - "User Experience", - "Transaction fees mechanisms", - "sequencer", - "Layer 2s", - "Transaction fees mechanisms", - "User Experience" - ], "keywords": [ - "Sequencing" + "Longevity" + ], + "tags": [ + "DeSci", + "e/acc" ], - "duration": 975, "language": "en", - "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d", - "sources_youtubeId": "-S2rlhSUHZY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731405600000, - "slot_end": 1731407400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc", - "resources_slides": null, "speakers": [ - "tina-haibodi" - ] + "nathan-cheng" + ], + "eventId": "devcon-7", + "slot_start": 1731557580000, + "slot_end": 1731558000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso" }, "vector": [ + 0, + 6, + 0, 0, 0, 0, @@ -751488,7 +752334,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -752235,7 +753080,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -752259,7 +753103,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -752285,7 +753128,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -752332,7 +753174,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -752359,6 +753200,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -752379,6 +753222,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -752781,12 +753625,11 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, 0, + 2, 0, 0, 2, @@ -752798,49 +753641,51 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-next-generation-of-decentralized-governance", - "sourceId": "WUSAHA", - "title": "The Next Generation of Decentralized Governance", - "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.", - "track": "Coordination", + "id": "the-next-700-evm-languages", + "sourceId": "QE7RWH", + "title": "The Next 700 EVM Languages", + "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.", + "track": "Developer Experience", "type": "Talk", "expertise": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [], "keywords": [ - "see", - "doc" + "programming languages", + "formal verification", + "smart contracts" + ], + "tags": [ + "Languages", + "Formal Verification", + "smart", + "contracts" ], - "duration": 1629, "language": "en", - "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603", - "sources_youtubeId": "VhkP2OIwIFY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt", - "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.", - "eventId": "devcon-7", - "slot_start": 1731403800000, - "slot_end": 1731405600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E", - "resources_slides": null, "speakers": [ - "tracheopteryx" - ] + "francisco-giordano" + ], + "eventId": "devcon-7", + "slot_start": 1731580200000, + "slot_end": 1731582000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y" }, "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -752849,7 +753694,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -753479,9 +754323,9 @@ 0, 0, 0, - 6, 0, 0, + 6, 0, 0, 0, @@ -753678,6 +754522,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -753779,6 +754624,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -753839,6 +754685,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -754143,7 +754991,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -754156,41 +755003,52 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-next-generation-of-governors-will-be-modular", - "sourceId": "DEAUWE", - "title": "The next generation of governors will be modular!", - "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.", - "track": "Coordination", - "type": "Lightning Talk", + "id": "the-next-era-sequencing-and-its-real-impact-on-app-users", + "sourceId": "9M78AK", + "title": "The Next Era: Sequencing and Its Real Impact on App Users", + "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.", + "track": "Usability", + "type": "Talk", "expertise": "Intermediate", - "audience": "Engineering", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Smart contracts", - "modularity" - ], "tags": [ - "Governance", - "Design", - "modular", - "Design", - "Governance" + "Layer 2s", + "User Experience", + "Transaction fees mechanisms", + "sequencer", + "Layer 2s", + "Transaction fees mechanisms", + "User Experience" ], - "language": "en", - "speakers": [ - "hadrien-croubois" + "keywords": [ + "Sequencing" ], + "duration": 975, + "language": "en", + "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d", + "sources_youtubeId": "-S2rlhSUHZY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731490200000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE" + "slot_start": 1731405600000, + "slot_end": 1731407400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc", + "resources_slides": null, + "speakers": [ + "tina-haibodi" + ] }, "vector": [ 0, @@ -754201,10 +755059,12 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, - 6, 0, 0, 0, @@ -754950,6 +755810,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -754972,6 +755834,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -754997,6 +755860,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -755028,7 +755892,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -755044,6 +755907,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -755075,7 +755939,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -755239,7 +756102,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -755498,11 +756360,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -755516,27 +756378,39 @@ }, { "session": { - "id": "the-open-source-orchestra", - "sourceId": "9PWLBV", - "title": "The Open Source Orchestra", - "description": "Member of the Open Source Orchestra", - "track": "Entertainment", - "type": "Music", - "expertise": "Expert", - "audience": "Engineering", + "id": "the-next-generation-of-decentralized-governance", + "sourceId": "WUSAHA", + "title": "The Next Generation of Decentralized Governance", + "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.", + "track": "Coordination", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [], "tags": [], - "language": "en", - "speakers": [ - "sophia-spirlock" + "keywords": [ + "see", + "doc" ], + "duration": 1629, + "language": "en", + "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603", + "sources_youtubeId": "VhkP2OIwIFY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt", + "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.", "eventId": "devcon-7", - "slot_start": 1731553200000, - "slot_end": 1731556800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY" + "slot_start": 1731403800000, + "slot_end": 1731405600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E", + "resources_slides": null, + "speakers": [ + "tracheopteryx" + ] }, "vector": [ 0, @@ -755548,6 +756422,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -756842,13 +757718,15 @@ 0, 0, 0, - 0, - 2, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -756862,34 +757740,48 @@ }, { "session": { - "id": "the-political-economy-of-dacc", - "sourceId": "AXX3JD", - "title": "The political economy of d/acc", - "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "the-next-generation-of-governors-will-be-modular", + "sourceId": "DEAUWE", + "title": "The next generation of governors will be modular!", + "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.", + "track": "Coordination", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "d/acc" + "Smart contracts", + "modularity" ], "tags": [ - "Public", - "good" + "Governance", + "Design", + "modular", + "Design", + "Governance" ], "language": "en", "speakers": [ - "eli-dourado" + "hadrien-croubois" ], "eventId": "devcon-7", - "slot_start": 1731553800000, - "slot_end": 1731555000000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk" + "slot_start": 1731489600000, + "slot_end": 1731490200000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE" }, "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 6, 0, @@ -757103,7 +757995,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -757527,6 +758418,25 @@ 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, @@ -757701,6 +758611,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -757744,6 +758658,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -757906,6 +758822,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -758141,37 +759059,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, @@ -758190,6 +759077,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -758200,8 +759088,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -758213,31 +759099,27 @@ }, { "session": { - "id": "the-rated-list", - "sourceId": "QNYDCR", - "title": "The Rated List", - "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", + "id": "the-open-source-orchestra", + "sourceId": "9PWLBV", + "title": "The Open Source Orchestra", + "description": "Member of the Open Source Orchestra", + "track": "Entertainment", + "type": "Music", + "expertise": "Expert", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], - "tags": [ - "DAS", - "Data Availability" - ], + "tags": [], "language": "en", "speakers": [ - "hopinheimer", - "chirag-mahaveer-parmar" + "sophia-spirlock" ], "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731487500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4" + "slot_start": 1731553200000, + "slot_end": 1731556800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY" }, "vector": [ 0, @@ -758249,13 +759131,16 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -758884,7 +759769,6 @@ 0, 0, 0, - 6, 6, 0, 0, @@ -759046,7 +759930,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -759334,7 +760217,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -759541,11 +760423,14 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 0, + 0, + 0, + 2, 2, 0, 0, @@ -759558,51 +760443,47 @@ 0, 0, 0, + 0, 0 ] }, { "session": { - "id": "the-ripple-effect-of-devcon-vi", - "sourceId": "E3U3XU", - "title": "The Ripple Effect of Devcon VI", - "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.", - "track": "Real World Ethereum", + "id": "the-political-economy-of-dacc", + "sourceId": "AXX3JD", + "title": "The political economy of d/acc", + "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", "type": "Lightning Talk", "expertise": "Beginner", "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Education" + "d/acc" ], "tags": [ - "Vision", - "Ethereum for Good", - "Local Impact", - "education", - "Ethereum for Good", - "Local Impact", - "Vision" + "Public", + "good" ], "language": "en", "speakers": [ - "julio-cesar-arango" + "eli-dourado" ], "eventId": "devcon-7", - "slot_start": 1731559800000, - "slot_end": 1731560400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak" + "slot_start": 1731553800000, + "slot_end": 1731555000000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk" }, "vector": [ 0, + 6, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -759810,6 +760691,9 @@ 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -760242,7 +761126,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -760426,7 +761309,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760461,7 +761343,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760571,7 +761452,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760580,7 +761460,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -760853,6 +761732,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -760919,40 +761804,31 @@ }, { "session": { - "id": "the-rise-of-ai-in-web3-development-ux", - "sourceId": "LTEX8X", - "title": "The Rise of AI in Web3 Development UX", - "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.", - "track": "Usability", + "id": "the-rated-list", + "sourceId": "QNYDCR", + "title": "The Rated List", + "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.", + "track": "[CLS] EPF Day", "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "AI Web3", - "LLM", - "Code Generation" - ], + "keywords": [], "tags": [ - "Tooling", - "User Experience", - "UI/UX", - "coding", - "generation", - "Tooling", - "UI/UX", - "User Experience" + "DAS", + "Data Availability" ], "language": "en", "speakers": [ - "stephane-tetsing" + "hopinheimer", + "chirag-mahaveer-parmar" ], "eventId": "devcon-7", - "slot_start": 1731565200000, - "slot_end": 1731565800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0" + "slot_start": 1731486600000, + "slot_end": 1731487500000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4" }, "vector": [ 0, @@ -760963,7 +761839,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -760971,6 +761846,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -761603,6 +762480,7 @@ 0, 0, 6, + 6, 0, 0, 0, @@ -761710,12 +762588,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -761753,7 +762629,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -761766,6 +762641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -762053,6 +762929,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -762207,8 +763086,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -762258,13 +763135,16 @@ 0, 0, 0, - 2, 0, 2, 0, 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -762278,41 +763158,37 @@ }, { "session": { - "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters", - "sourceId": "SEARYQ", - "title": "The rise of Appchains: from L2s to Rollup Clusters", - "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", + "id": "the-ripple-effect-of-devcon-vi", + "sourceId": "E3U3XU", + "title": "The Ripple Effect of Devcon VI", + "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "Fragmentation", - "UX", - "interoperability", - "Rollup Clusters", - "L2" + "Education" ], "tags": [ - "Ethereum Roadmap", - "Appchains", - "Zero-Knowledge", - "interoperability", - "Appchains", - "Ethereum Roadmap", - "Zero-Knowledge" + "Vision", + "Ethereum for Good", + "Local Impact", + "education", + "Ethereum for Good", + "Local Impact", + "Vision" ], "language": "en", "speakers": [ - "alex-gluchowski" + "julio-cesar-arango" ], "eventId": "devcon-7", - "slot_start": 1731493800000, - "slot_end": 1731495600000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA" + "slot_start": 1731559800000, + "slot_end": 1731560400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak" }, "vector": [ 0, @@ -762321,7 +763197,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -762963,6 +763838,9 @@ 0, 0, 0, + 0, + 0, + 0, 6, 0, 0, @@ -763066,7 +763944,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -763148,6 +764025,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -763180,6 +764060,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -763248,7 +764129,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -763290,6 +764170,21 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -763383,7 +764278,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -763446,18 +764340,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -763620,12 +764502,10 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -763638,41 +764518,40 @@ }, { "session": { - "id": "the-role-of-culture-in-shaping-technology-the-case-against-tech-neo-colonialism", - "sourceId": "LRJTXY", - "title": "The role of culture in shaping technology - the case against tech-neo-colonialism", - "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.", - "track": "Real World Ethereum", + "id": "the-rise-of-ai-in-web3-development-ux", + "sourceId": "LTEX8X", + "title": "The Rise of AI in Web3 Development UX", + "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.", + "track": "Usability", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Developer", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Philosophy", - "Diversity", - "Democracy" + "AI Web3", + "LLM", + "Code Generation" ], "tags": [ - "Network State", - "Digital Sovereignty", - "Decentralization", - "diversity", - "democracy", - "philosophy", - "Decentralization", - "Digital Sovereignty", - "Network State" + "Tooling", + "User Experience", + "UI/UX", + "coding", + "generation", + "Tooling", + "UI/UX", + "User Experience" ], "language": "en", "speakers": [ - "fatemeh-fannizadeh" + "stephane-tetsing" ], "eventId": "devcon-7", - "slot_start": 1731560400000, - "slot_end": 1731561000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k" + "slot_start": 1731565200000, + "slot_end": 1731565800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0" }, "vector": [ 0, @@ -763681,6 +764560,8 @@ 0, 0, 0, + 0, + 0, 6, 0, 0, @@ -764281,7 +765162,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -764325,6 +765205,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -764432,10 +765313,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -764461,10 +765344,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -764475,6 +765356,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -764516,7 +765399,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -764544,7 +765426,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -764978,9 +765859,9 @@ 0, 0, 0, - 2, 0, 0, + 2, 0, 2, 0, @@ -764993,45 +765874,48 @@ 0, 0, 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-shape-of-protocols-to-come", - "sourceId": "TYGBPN", - "title": "The Shape of Protocols to Come", - "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.", - "track": "Coordination", + "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters", + "sourceId": "SEARYQ", + "title": "The rise of Appchains: from L2s to Rollup Clusters", + "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr", + "track": "Layer 2", "type": "Talk", - "expertise": "Beginner", + "expertise": "Intermediate", "audience": "Engineering", - "featured": true, + "featured": false, "doNotRecord": false, + "keywords": [ + "Fragmentation", + "UX", + "interoperability", + "Rollup Clusters", + "L2" + ], "tags": [ "Ethereum Roadmap", - "Protocol Design", - "Use Cases" + "Appchains", + "Zero-Knowledge", + "interoperability", + "Appchains", + "Ethereum Roadmap", + "Zero-Knowledge" ], - "keywords": [], - "duration": 1402, "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "t_2ZIfF9gMc", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", + "speakers": [ + "alex-gluchowski" + ], "eventId": "devcon-7", - "slot_start": 1731409200000, - "slot_end": 1731411000000, + "slot_start": 1731493800000, + "slot_end": 1731495600000, "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw", - "resources_slides": null, - "speakers": [ - "tim-beiko" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA" }, "vector": [ 0, @@ -765041,11 +765925,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -765224,7 +766108,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -765687,6 +766570,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -765788,6 +766673,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -765819,7 +766705,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -765852,7 +766737,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -765967,11 +766851,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -766106,6 +766990,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -766168,6 +767053,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -766339,6 +767225,8 @@ 0, 2, 0, + 0, + 0, 2, 0, 0, @@ -766357,44 +767245,50 @@ }, { "session": { - "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices", - "sourceId": "D8UTDS", - "title": "The Silicon Hospital and a New Way to Make Medical Devices", - "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "id": "the-role-of-culture-in-shaping-technology-the-case-against-tech-neo-colonialism", + "sourceId": "LRJTXY", + "title": "The role of culture in shaping technology - the case against tech-neo-colonialism", + "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.", + "track": "Real World Ethereum", "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Community", + "audience": "Developer", "featured": false, "doNotRecord": false, "keywords": [ - "Healthcare", - "", - "Medical" + "Philosophy", + "Diversity", + "Democracy" ], "tags": [ - "DeSci", - "Open Source Software", - "Scalability" + "Network State", + "Digital Sovereignty", + "Decentralization", + "diversity", + "democracy", + "philosophy", + "Decentralization", + "Digital Sovereignty", + "Network State" ], "language": "en", "speakers": [ - "mary-lou-jepsen" + "fatemeh-fannizadeh" ], "eventId": "devcon-7", - "slot_start": 1731573600000, - "slot_end": 1731574500000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ" + "slot_start": 1731560400000, + "slot_end": 1731561000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k" }, "vector": [ 0, - 6, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -766998,6 +767892,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -767037,7 +767932,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -767178,8 +768072,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -767225,13 +768121,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -767259,15 +768155,14 @@ 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -767645,6 +768540,9 @@ 0, 0, 0, + 2, + 2, + 0, 0, 0, 0, @@ -767695,10 +768593,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -767711,43 +768609,39 @@ }, { "session": { - "id": "the-state-of-web3-support-today-what-just-happened", - "sourceId": "BZRKUD", - "title": "The State of Web3 Support Today: What Just Happened?", - "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.", - "track": "Usability", - "type": "Lightning Talk", + "id": "the-shape-of-protocols-to-come", + "sourceId": "TYGBPN", + "title": "The Shape of Protocols to Come", + "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.", + "track": "Coordination", + "type": "Talk", "expertise": "Beginner", - "audience": "Product", - "featured": false, + "audience": "Engineering", + "featured": true, "doNotRecord": false, "tags": [ - "community", - "Accessibility", - "Tooling", - "User Experience" - ], - "keywords": [ - "User Support", - "Community" + "Ethereum Roadmap", + "Protocol Design", + "Use Cases" ], - "duration": 304, + "keywords": [], + "duration": 1402, "language": "en", - "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4", - "sources_youtubeId": "sur3bRJQw-U", + "sources_swarmHash": "", + "sources_youtubeId": "t_2ZIfF9gMc", "sources_ipfsHash": "", "sources_livepeerId": "", "sources_streamethId": null, "transcript_vtt": "No VTT link provided", "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731408600000, - "slot_end": 1731409200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k", + "slot_start": 1731409200000, + "slot_end": 1731411000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw", "resources_slides": null, "speakers": [ - "fungible-taco" + "tim-beiko" ] }, "vector": [ @@ -767759,15 +768653,10 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, + 6, 0, 0, 0, @@ -767947,6 +768836,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -768401,7 +769291,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -768506,12 +769395,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -768547,10 +769434,10 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, 0, @@ -768580,6 +769467,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -768666,7 +769554,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -768695,6 +769582,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -769054,12 +769945,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 0, + 0, + 2, + 0, 2, 0, 0, @@ -769069,45 +769963,49 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 0 ] }, { "session": { - "id": "the-supreme-ruler-of-the-world", - "sourceId": "TLWWCW", - "title": "The Supreme Ruler of the World", - "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.", - "track": "Applied Cryptography", - "type": "Talk", + "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices", + "sourceId": "D8UTDS", + "title": "The Silicon Hospital and a New Way to Make Medical Devices", + "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", "expertise": "Beginner", - "audience": "Engineering", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "sumcalc", - "sumcheck" + "Healthcare", + "", + "Medical" ], "tags": [ - "Scalability", - "Validiums", - "Zero-Knowledge", - "sumcheck", - "Scalability", - "Validiums", - "Zero-Knowledge" + "DeSci", + "Open Source Software", + "Scalability" ], "language": "en", "speakers": [ - "don-beaver" + "mary-lou-jepsen" ], "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o" + "slot_start": 1731573600000, + "slot_end": 1731574500000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ" }, "vector": [ + 0, + 6, + 0, 0, 0, 0, @@ -769118,7 +770016,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -769859,7 +770756,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -769948,6 +770844,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -769982,6 +770880,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -770300,7 +771199,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770364,7 +771262,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -770411,7 +771308,7 @@ 0, 0, 0, - 2, + 0, 0, 2, 0, @@ -770420,6 +771317,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -770431,50 +771330,56 @@ }, { "session": { - "id": "the-tension-between-mev-and-censorship-resistance-gadgets", - "sourceId": "G3MBF7", - "title": "The tension between MEV and Censorship Resistance Gadgets", - "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", + "id": "the-state-of-web3-support-today-what-just-happened", + "sourceId": "BZRKUD", + "title": "The State of Web3 Support Today: What Just Happened?", + "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", "featured": false, "doNotRecord": false, - "keywords": [ - "Inclusion Lists", - "Protocol Design" - ], "tags": [ - "Ethereum Roadmap", - "Censorship Resistance", - "Design", - "MEV", - "protocol", - "Censorship Resistance", - "Ethereum Roadmap", - "MEV" + "community", + "Accessibility", + "Tooling", + "User Experience" ], - "language": "en", - "speakers": [ - "julian-ma" + "keywords": [ + "User Support", + "Community" ], + "duration": 304, + "language": "en", + "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4", + "sources_youtubeId": "sur3bRJQw-U", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731641400000, - "slot_end": 1731643200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU" + "slot_start": 1731408600000, + "slot_end": 1731409200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k", + "resources_slides": null, + "speakers": [ + "fungible-taco" + ] }, "vector": [ 0, 0, - 6, 0, 0, 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -771068,7 +771973,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -771120,6 +772024,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -771207,7 +772112,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -771225,10 +772129,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -771267,6 +772173,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -771348,12 +772255,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -771384,6 +772289,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -771399,7 +772307,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -771596,7 +772503,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -771770,7 +772676,6 @@ 0, 0, 0, - 2, 0, 2, 0, @@ -771778,6 +772683,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -771789,97 +772697,40 @@ }, { "session": { - "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy", - "sourceId": "JESAHN", - "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy", - "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.", - "track": "Layer 2", + "id": "the-supreme-ruler-of-the-world", + "sourceId": "TLWWCW", + "title": "The Supreme Ruler of the World", + "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.", + "track": "Applied Cryptography", "type": "Talk", - "expertise": "Intermediate", + "expertise": "Beginner", "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [ - "Wallets" + "sumcalc", + "sumcheck" ], "tags": [ - "Zk Rollups", - "Cross-L2", - "Account Abstraction", - "wallet", - "Account Abstraction", - "Cross-L2", - "Zk Rollups" + "Scalability", + "Validiums", + "Zero-Knowledge", + "sumcheck", + "Scalability", + "Validiums", + "Zero-Knowledge" ], "language": "en", "speakers": [ - "niran-babalola" + "don-beaver" ], "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q" + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o" }, "vector": [ - 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, @@ -771890,6 +772741,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -772474,7 +773326,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -772535,6 +773386,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -772612,7 +773464,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -772630,12 +773481,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -772989,16 +773840,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -773086,6 +773927,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -773123,11 +773965,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -773140,67 +773980,18 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-trustless-trade-supply-chain", - "sourceId": "RQZADG", - "title": "The Trustless Trade Supply Chain", - "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "PBS", - "MEV", - "Trading", - "Intents", - "TEE", - "Intents", - "MEV", - "PBS", - "Trading" - ], - "keywords": [ - "TEE" - ], - "duration": 460, - "language": "en", - "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a", - "sources_youtubeId": "9EPCog8GiiQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt", - "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", - "eventId": "devcon-7", - "slot_start": 1731410400000, - "slot_end": 1731411000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A", - "resources_slides": null, - "speakers": [ - "markus" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -773247,7 +774038,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -773260,8 +774053,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-tension-between-mev-and-censorship-resistance-gadgets", + "sourceId": "G3MBF7", + "title": "The tension between MEV and Censorship Resistance Gadgets", + "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Inclusion Lists", + "Protocol Design" + ], + "tags": [ + "Ethereum Roadmap", + "Censorship Resistance", + "Design", + "MEV", + "protocol", + "Censorship Resistance", + "Ethereum Roadmap", + "MEV" + ], + "language": "en", + "speakers": [ + "julian-ma" + ], + "eventId": "devcon-7", + "slot_start": 1731641400000, + "slot_end": 1731643200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -773842,7 +774676,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -773866,6 +774699,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -773930,7 +774764,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -773967,7 +774800,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -773983,7 +774815,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -774007,10 +774838,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 2, 0, 0, 0, @@ -774148,10 +774979,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -774197,6 +775030,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -774260,7 +775094,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -774394,6 +775227,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -774490,12 +775324,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -774507,57 +775339,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-verge-is-not-going-to-break-your-contracts", - "sourceId": "NJXNE3", - "title": "The verge is (not) going to break your contracts!", - "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Expert", - "audience": "Developper", - "featured": false, - "doNotRecord": false, - "keywords": [ - "compiler" - ], - "tags": [ - "Verkle trees", - "Libraries", - "Best Practices", - "compilers", - "Best Practices", - "Libraries", - "Verkle trees" - ], - "language": "en", - "speakers": [ - "hadrien-croubois" - ], - "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731493800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE" - }, - "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -774620,7 +775401,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -774632,6 +775415,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy", + "sourceId": "JESAHN", + "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy", + "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Wallets" + ], + "tags": [ + "Zk Rollups", + "Cross-L2", + "Account Abstraction", + "wallet", + "Account Abstraction", + "Cross-L2", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "niran-babalola" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q" + }, + "vector": [ 0, 0, 0, @@ -774639,6 +775460,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -775187,7 +776009,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -775288,6 +776109,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -775295,7 +776117,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -775315,7 +776136,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775427,6 +776247,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -775444,6 +776265,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -775479,7 +776301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775515,7 +776336,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775578,6 +776398,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -775803,6 +776624,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -775849,7 +776671,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -775858,52 +776679,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-verifiability-vision", - "sourceId": "KXRMGY", - "title": "The verifiability vision", - "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Verifiability", - "proof carrying data", - "succinct proofs" - ], - "tags": [ - "Scalability", - "Vision", - "ZKP", - "proof", - "succinct", - "Scalability", - "Vision", - "ZKP" - ], - "language": "en", - "speakers": [ - "jens-groth" - ], - "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731580200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg" - }, - "vector": [ 0, 0, 0, @@ -775914,7 +776693,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -775980,9 +776758,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -775995,12 +776775,62 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-trustless-trade-supply-chain", + "sourceId": "RQZADG", + "title": "The Trustless Trade Supply Chain", + "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "PBS", + "MEV", + "Trading", + "Intents", + "TEE", + "Intents", + "MEV", + "PBS", + "Trading" + ], + "keywords": [ + "TEE" + ], + "duration": 460, + "language": "en", + "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a", + "sources_youtubeId": "9EPCog8GiiQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt", + "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you", + "eventId": "devcon-7", + "slot_start": 1731410400000, + "slot_end": 1731411000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A", + "resources_slides": null, + "speakers": [ + "markus" + ] + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -776558,7 +777388,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -776652,6 +777481,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -776718,7 +777548,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -776740,6 +777569,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -776776,6 +777606,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776783,7 +777614,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -776792,6 +777622,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776818,6 +777649,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -776869,7 +777701,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -776879,7 +777710,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -777069,6 +777899,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -777161,7 +777992,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -777205,12 +778035,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -777222,49 +778050,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-verkle-advantage", - "sourceId": "YLBEZN", - "title": "The verkle advantage", - "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "stateless" - ], - "tags": [ - "Core Protocol", - "Protocol Design", - "Verkle trees", - "stateless", - "Core Protocol", - "Protocol Design", - "Verkle trees" - ], - "language": "en", - "speakers": [ - "guillaume-ballet" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731490200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -777340,10 +778129,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -777355,9 +778146,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-verge-is-not-going-to-break-your-contracts", + "sourceId": "NJXNE3", + "title": "The verge is (not) going to break your contracts!", + "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Expert", + "audience": "Developper", + "featured": false, + "doNotRecord": false, + "keywords": [ + "compiler" + ], + "tags": [ + "Verkle trees", + "Libraries", + "Best Practices", + "compilers", + "Best Practices", + "Libraries", + "Verkle trees" + ], + "language": "en", + "speakers": [ + "hadrien-croubois" + ], + "eventId": "devcon-7", + "slot_start": 1731492000000, + "slot_end": 1731493800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -777915,7 +778745,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -778001,6 +778830,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -778018,7 +778848,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -778045,7 +778874,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -778110,6 +778938,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -778129,6 +778958,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -778194,7 +779024,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -778293,6 +779122,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -778328,6 +779158,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -778518,7 +779351,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -778561,11 +779393,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -778578,46 +779408,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses", - "sourceId": "LCNEGW", - "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses", - "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).", - "track": "Usability", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Wallets", - "Signers", - "Permissions" - ], - "tags": [ - "Developer Infrastructure", - "User Experience", - "Account Abstraction", - "permissions", - "Account Abstraction", - "Developer Infrastructure", - "User Experience" - ], - "language": "en", - "speakers": [ - "nichanan-kesonpat" - ], - "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731472200000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0" - }, - "vector": [ 0, 0, 0, @@ -778626,7 +779416,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -778703,6 +779492,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -778711,10 +779501,52 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-verifiability-vision", + "sourceId": "KXRMGY", + "title": "The verifiability vision", + "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Verifiability", + "proof carrying data", + "succinct proofs" + ], + "tags": [ + "Scalability", + "Vision", + "ZKP", + "proof", + "succinct", + "Scalability", + "Vision", + "ZKP" + ], + "language": "en", + "speakers": [ + "jens-groth" + ], + "eventId": "devcon-7", + "slot_start": 1731578400000, + "slot_end": 1731580200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg" + }, + "vector": [ 0, 0, 0, @@ -778725,6 +779557,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -779274,7 +780107,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -779408,10 +780240,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -779535,6 +780365,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -779595,6 +780430,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -779680,6 +780516,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -779689,6 +780526,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -779877,7 +780715,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -779919,7 +780756,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -779927,7 +780763,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -779936,68 +780771,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "the-wellbeing-protocol-scaling-localism", - "sourceId": "HC3QGN", - "title": "The Wellbeing Protocol - Scaling Localism", - "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "conviction", - "zealand" - ], - "tags": [ - "DAO", - "Governance", - "Quadratic Voting", - "Collective Intelligence", - "Conviction", - "Ethereum for Good", - "Public good", - "Climate", - "ReFi", - "Regenerative Applications", - "User Experience", - "zealand", - "Climate", - "Collective Intelligence", - "Conviction", - "DAO", - "Ethereum for Good", - "Governance", - "Public good", - "Quadratic Voting", - "ReFi", - "Regenerative Applications", - "User Experience" - ], - "language": "en", - "speakers": [ - "mark-pascall" - ], - "eventId": "devcon-7", - "slot_start": 1731481200000, - "slot_end": 1731481800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -780029,6 +780808,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -780072,10 +780852,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -780087,10 +780869,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-verkle-advantage", + "sourceId": "YLBEZN", + "title": "The verkle advantage", + "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "stateless" + ], + "tags": [ + "Core Protocol", + "Protocol Design", + "Verkle trees", + "stateless", + "Core Protocol", + "Protocol Design", + "Verkle trees" + ], + "language": "en", + "speakers": [ + "guillaume-ballet" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731490200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -780648,7 +781469,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -780764,14 +781584,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -780826,12 +781638,7 @@ 0, 0, 0, - 2, - 0, - 0, - 0, 0, - 2, 0, 0, 0, @@ -780839,7 +781646,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -780856,12 +781662,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -780892,6 +781696,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -780941,15 +781746,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -781049,6 +781845,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -781155,7 +781952,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -781251,8 +782047,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -781294,14 +782088,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -781309,43 +782101,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "things-you-didnt-know-about-contract-deployment", - "sourceId": "GJM9UC", - "title": "Things you didn't know about contract deployment", - "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Deployment" - ], - "tags": [ - "deployment" - ], - "language": "en", - "speakers": [ - "theresa-wakonig" - ], - "eventId": "devcon-7", - "slot_start": 1731470400000, - "slot_end": 1731471000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -781410,6 +782169,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -781452,9 +782212,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -781467,6 +782229,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses", + "sourceId": "LCNEGW", + "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses", + "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).", + "track": "Usability", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Wallets", + "Signers", + "Permissions" + ], + "tags": [ + "Developer Infrastructure", + "User Experience", + "Account Abstraction", + "permissions", + "Account Abstraction", + "Developer Infrastructure", + "User Experience" + ], + "language": "en", + "speakers": [ + "nichanan-kesonpat" + ], + "eventId": "devcon-7", + "slot_start": 1731470400000, + "slot_end": 1731472200000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0" + }, + "vector": [ 0, 0, 0, @@ -781475,6 +782277,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -781999,7 +782802,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -782127,6 +782929,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -782225,6 +783028,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -782259,8 +783063,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -782431,7 +783237,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -782642,13 +783447,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -782659,51 +783462,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "this-cursed-machine-post-mortem", - "sourceId": "UBFQ9V", - "title": "THIS CURSED MACHINE Post-Mortem", - "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Worldbuilding" - ], - "tags": [ - "Best Practices", - "Gaming", - "Autonomous World", - "worldbuilding", - "Autonomous World", - "Best Practices", - "Gaming" - ], - "language": "en", - "speakers": [ - "arb" - ], - "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -782768,6 +783532,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -782809,6 +783574,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -782816,6 +783582,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -782824,12 +783591,68 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "the-wellbeing-protocol-scaling-localism", + "sourceId": "HC3QGN", + "title": "The Wellbeing Protocol - Scaling Localism", + "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "conviction", + "zealand" + ], + "tags": [ + "DAO", + "Governance", + "Quadratic Voting", + "Collective Intelligence", + "Conviction", + "Ethereum for Good", + "Public good", + "Climate", + "ReFi", + "Regenerative Applications", + "User Experience", + "zealand", + "Climate", + "Collective Intelligence", + "Conviction", + "DAO", + "Ethereum for Good", + "Governance", + "Public good", + "Quadratic Voting", + "ReFi", + "Regenerative Applications", + "User Experience" + ], + "language": "en", + "speakers": [ + "mark-pascall" + ], + "eventId": "devcon-7", + "slot_start": 1731481200000, + "slot_end": 1731481800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -783356,7 +784179,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -783467,7 +784289,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -783486,6 +784307,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -783546,8 +784368,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -783585,6 +784405,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -783602,6 +784423,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -783663,10 +784485,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -783674,6 +784498,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -783690,13 +784515,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -783772,6 +784600,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -783959,7 +784788,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -783986,6 +784814,13 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -784000,13 +784835,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -784015,43 +784848,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "this-year-in-ethereum", - "sourceId": "MFBX7X", - "title": "This year in Ethereum", - "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "josh-stark" - ], - "eventId": "devcon-7", - "slot_start": 1731381300000, - "slot_end": 1731382800000, - "slot_roomId": "main-stage", - "sources_youtubeId": "YyK8i2-0aPk", - "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a", - "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -784108,6 +784910,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -784147,21 +784953,58 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, + 2, + 0, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "things-you-didnt-know-about-contract-deployment", + "sourceId": "GJM9UC", + "title": "Things you didn't know about contract deployment", + "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Deployment" + ], + "tags": [ + "deployment" + ], + "language": "en", + "speakers": [ + "theresa-wakonig" + ], + "eventId": "devcon-7", + "slot_start": 1731470400000, + "slot_end": 1731471000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -784705,7 +785548,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -784820,6 +785662,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -785251,6 +786094,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -785347,10 +786191,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -785363,53 +786205,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum", - "sourceId": "QNSX9R", - "title": "Time is all you need: optimizing Dutch auctions on Arbitrum", - "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring the optimal auction execution times, as well as optimal decay curves, for blockchain based trading. Using simulations and real data, we present our findings on this topic, as well as proposed solutions to achieve the optimal outcomes.", - "track": "Cryptoeconomics", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Dutch", - "auctions" - ], - "tags": [ - "Decentralization Improvements", - "Layer 2s", - "Mechanism design", - "MEV", - "auction", - "dutch", - "Decentralization Improvements", - "Layer 2s", - "Mechanism design", - "MEV" - ], - "language": "en", - "speakers": [ - "brad-bachu", - "cody-born", - "alan-wu" - ], - "eventId": "devcon-7", - "slot_start": 1731489000000, - "slot_end": 1731489600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -785508,11 +786305,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -785523,12 +786322,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "this-cursed-machine-post-mortem", + "sourceId": "UBFQ9V", + "title": "THIS CURSED MACHINE Post-Mortem", + "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Worldbuilding" + ], + "tags": [ + "Best Practices", + "Gaming", + "Autonomous World", + "worldbuilding", + "Autonomous World", + "Best Practices", + "Gaming" + ], + "language": "en", + "speakers": [ + "arb" + ], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -786068,9 +786906,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -786148,12 +786983,9 @@ 0, 0, 0, - 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -786191,6 +787023,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -786212,7 +787045,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -786302,6 +787134,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -786380,6 +787213,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -786474,7 +787309,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -786670,7 +787504,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -786708,12 +787541,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -786725,46 +787556,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data", - "sourceId": "RTVKJC", - "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data", - "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it", - "track": "Applied Cryptography", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "User Sovereignty", - "Infrastructure", - "Oracle" - ], - "tags": [ - "Identity", - "ZKP", - "MPC", - "oracle", - "Identity", - "MPC", - "ZKP" - ], - "language": "en", - "speakers": [ - "sinu" - ], - "eventId": "devcon-7", - "slot_start": 1731576600000, - "slot_end": 1731577200000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo" - }, - "vector": [ 0, 0, 0, @@ -786775,7 +787566,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -786836,6 +787626,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -786876,11 +787667,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -786889,12 +787682,43 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "this-year-in-ethereum", + "sourceId": "MFBX7X", + "title": "This year in Ethereum", + "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "josh-stark" + ], + "eventId": "devcon-7", + "slot_start": 1731381300000, + "slot_end": 1731382800000, + "slot_roomId": "main-stage", + "sources_youtubeId": "YyK8i2-0aPk", + "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a", + "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -787429,7 +788253,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -787553,7 +788376,7 @@ 0, 0, 0, - 2, + 6, 0, 0, 0, @@ -787579,7 +788402,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -787593,7 +788415,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -787942,7 +788763,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -788066,11 +788886,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -788083,48 +788901,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient", - "sourceId": "Z8EEGW", - "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient", - "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "statelessness" - ], - "tags": [ - "Light Clients", - "Zero-Knowledge", - "statelessness", - "Light Clients", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "jason-chaskin", - "gajinder-singh" - ], - "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731492000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -788238,8 +789018,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -788252,8 +789034,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum", + "sourceId": "QNSX9R", + "title": "Time is all you need: optimizing Dutch auctions on Arbitrum", + "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring the optimal auction execution times, as well as optimal decay curves, for blockchain based trading. Using simulations and real data, we present our findings on this topic, as well as proposed solutions to achieve the optimal outcomes.", + "track": "Cryptoeconomics", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Dutch", + "auctions" + ], + "tags": [ + "Decentralization Improvements", + "Layer 2s", + "Mechanism design", + "MEV", + "auction", + "dutch", + "Decentralization Improvements", + "Layer 2s", + "Mechanism design", + "MEV" + ], + "language": "en", + "speakers": [ + "brad-bachu", + "cody-born", + "alan-wu" + ], + "eventId": "devcon-7", + "slot_start": 1731489000000, + "slot_end": 1731489600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -788785,8 +789612,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -788871,7 +789696,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -788879,7 +789703,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -788920,6 +789743,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -788997,9 +789823,12 @@ 0, 0, 0, + 6, 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -789058,6 +789887,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -789319,6 +790149,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -789384,7 +790215,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -789421,11 +790251,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -789438,51 +790266,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "tomo-dj-set", - "sourceId": "3FTAT3", - "title": "Tomo DJ Set", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731583800000, - "slot_end": 1731588600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -789562,6 +790345,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -789599,10 +790383,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -789614,6 +790400,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data", + "sourceId": "RTVKJC", + "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data", + "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it", + "track": "Applied Cryptography", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "User Sovereignty", + "Infrastructure", + "Oracle" + ], + "tags": [ + "Identity", + "ZKP", + "MPC", + "oracle", + "Identity", + "MPC", + "ZKP" + ], + "language": "en", + "speakers": [ + "sinu" + ], + "eventId": "devcon-7", + "slot_start": 1731576600000, + "slot_end": 1731577200000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo" + }, + "vector": [ 0, 0, 0, @@ -789624,6 +790450,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -790281,6 +791108,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -790404,6 +791232,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -790429,6 +791258,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -790442,6 +791272,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -790766,75 +791597,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "top-hacks-since-devcon-vi-what-did-we-learn", - "sourceId": "FCWCBG", - "title": "Top Hacks since Devcon VI: what did we learn?", - "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!", - "track": "Security", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Learnings", - "War Rooms" - ], - "tags": [ - "Security", - "Hacks", - "Use Cases", - "war", - "room", - "Hacks", - "Security", - "Use Cases" - ], - "language": "en", - "speakers": [ - "matthias-egli", - "mudit-gupta" - ], - "eventId": "devcon-7", - "slot_start": 1731483000000, - "slot_end": 1731488400000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE" - }, - "vector": [ - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -790859,6 +791621,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -790982,9 +791745,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -790997,10 +791762,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient", + "sourceId": "Z8EEGW", + "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient", + "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "statelessness" + ], + "tags": [ + "Light Clients", + "Zero-Knowledge", + "statelessness", + "Light Clients", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "jason-chaskin", + "gajinder-singh" + ], + "eventId": "devcon-7", + "slot_start": 1731490200000, + "slot_end": 1731492000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -791075,7 +791878,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -791270,7 +792072,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -791562,7 +792363,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -791641,7 +792441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -791669,6 +792468,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -791753,6 +792554,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -791760,6 +792562,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -791814,7 +792617,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -792088,8 +792890,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -792124,11 +792924,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -792141,53 +792939,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "top-opcode-offenders-in-the-zkevm", - "sourceId": "DJL7RP", - "title": "Top opcode offenders in the zkEVM", - "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "zk-resources", - "GAS costs", - "top offenders" - ], - "tags": [ - "Core Protocol", - "Layer 2s", - "Zk Rollups", - "top", - "offenders", - "Core Protocol", - "Layer 2s", - "Zk Rollups" - ], - "language": "en", - "speakers": [ - "carlos-matallana", - "jesus" - ], - "eventId": "devcon-7", - "slot_start": 1731490200000, - "slot_end": 1731492000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -792312,6 +793067,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -792348,9 +793104,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -792363,6 +793121,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "tomo-dj-set", + "sourceId": "3FTAT3", + "title": "Tomo DJ Set", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731583800000, + "slot_end": 1731588600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU" + }, + "vector": [ 0, 0, 0, @@ -792372,6 +793156,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -792688,7 +793473,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -792850,7 +793634,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -792941,7 +793724,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -792988,10 +793770,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -793450,8 +794230,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -793487,8 +794265,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -793501,37 +794277,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "tracing-integration-in-lighthouse", - "sourceId": "RVZX3C", - "title": "Tracing Integration in Lighthouse", - "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Core Protocol", - "Frameworks" - ], - "language": "en", - "speakers": [ - "sayan" - ], - "eventId": "devcon-7", - "slot_start": 1731474900000, - "slot_end": 1731475800000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE" - }, - "vector": [ 0, 0, 0, @@ -793547,7 +794292,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -793709,8 +794453,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -793723,6 +794469,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "top-hacks-since-devcon-vi-what-did-we-learn", + "sourceId": "FCWCBG", + "title": "Top Hacks since Devcon VI: what did we learn?", + "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!", + "track": "Security", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Learnings", + "War Rooms" + ], + "tags": [ + "Security", + "Hacks", + "Use Cases", + "war", + "room", + "Hacks", + "Security", + "Use Cases" + ], + "language": "en", + "speakers": [ + "matthias-egli", + "mudit-gupta" + ], + "eventId": "devcon-7", + "slot_start": 1731483000000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE" + }, + "vector": [ + 6, 0, 0, 0, @@ -793975,6 +794763,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -794170,6 +794959,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -794200,7 +794990,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -794290,7 +795079,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -794376,7 +795164,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -794466,6 +795253,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -794544,6 +795332,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -794716,6 +795505,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -794835,9 +795625,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -794850,54 +795638,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "transaction-simulation-the-good-the-bad-and-the-ugly", - "sourceId": "TE9JUF", - "title": "Transaction simulation, the good, the bad & the ugly", - "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years", - "track": "Security", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Security", - "User Experience", - "safety", - "Security", - "User Experience" - ], - "keywords": [ - "simulation", - "wallet", - "safety" - ], - "duration": 458, - "language": "en", - "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f", - "sources_youtubeId": "6-ygj7_IqEg", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt", - "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you", - "eventId": "devcon-7", - "slot_start": 1731409800000, - "slot_end": 1731410400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4", - "resources_slides": null, - "speakers": [ - "kim-persson" - ] - }, - "vector": [ - 6, 0, 0, 0, @@ -795039,6 +795779,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -795073,9 +795815,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -795088,10 +795832,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "top-opcode-offenders-in-the-zkevm", + "sourceId": "DJL7RP", + "title": "Top opcode offenders in the zkEVM", + "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "zk-resources", + "GAS costs", + "top offenders" + ], + "tags": [ + "Core Protocol", + "Layer 2s", + "Zk Rollups", + "top", + "offenders", + "Core Protocol", + "Layer 2s", + "Zk Rollups" + ], + "language": "en", + "speakers": [ + "carlos-matallana", + "jesus" + ], + "eventId": "devcon-7", + "slot_start": 1731490200000, + "slot_end": 1731492000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -795566,7 +796353,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -795595,6 +796381,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -795636,7 +796423,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -795652,7 +796438,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -795760,6 +796545,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -795850,6 +796636,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -795896,6 +796683,20 @@ 0, 0, 0, + 2, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -795937,7 +796738,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -796198,11 +796998,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -796215,42 +797013,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "transforming-systems-lessons-from-taiwans-movements", - "sourceId": "B9EDKY", - "title": "Transforming Systems: Lessons from Taiwan's Movements", - "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.", - "track": "Coordination", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Ecosystem", - "Funding", - "Mainstream" - ], - "tags": [ - "Civil Resistance", - "Coordination", - "Public good" - ], - "language": "en", - "speakers": [ - "noah-yeh" - ], - "eventId": "devcon-7", - "slot_start": 1731638700000, - "slot_end": 1731639900000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk" - }, - "vector": [ 0, 0, 0, @@ -796262,7 +797024,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -796384,6 +797145,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -796417,6 +797182,11 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -796426,6 +797196,37 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "tracing-integration-in-lighthouse", + "sourceId": "RVZX3C", + "title": "Tracing Integration in Lighthouse", + "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Core Protocol", + "Frameworks" + ], + "language": "en", + "speakers": [ + "sayan" + ], + "eventId": "devcon-7", + "slot_start": 1731474900000, + "slot_end": 1731475800000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE" + }, + "vector": [ 0, 0, 0, @@ -796441,6 +797242,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -796921,7 +797723,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -797098,8 +797899,8 @@ 0, 0, 0, + 6, 0, - 2, 0, 0, 0, @@ -797145,7 +797946,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -797189,6 +797989,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -797222,7 +798023,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -797275,6 +798075,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -797554,14 +798355,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -797569,53 +798368,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "transitioning-from-an-l1-to-an-l2-a-case-study", - "sourceId": "KHVZ9M", - "title": "Transitioning from an L1 to an L2: A case study", - "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Layer2", - "case study", - "technical learnings" - ], - "tags": [ - "Layer 1", - "Layer 2s", - "Rollups", - "Scalability", - "Optimistic rollups", - "Use Cases", - "learnings", - "technical", - "Layer 1", - "Layer 2s", - "Optimistic rollups", - "Rollups", - "Scalability", - "Use Cases" - ], - "language": "en", - "speakers": [ - "marek-olszewski" - ], - "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg" - }, - "vector": [ 0, 0, 0, @@ -797623,7 +798375,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -797783,7 +798534,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -797796,6 +798549,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "transaction-simulation-the-good-the-bad-and-the-ugly", + "sourceId": "TE9JUF", + "title": "Transaction simulation, the good, the bad & the ugly", + "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years", + "track": "Security", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Security", + "User Experience", + "safety", + "Security", + "User Experience" + ], + "keywords": [ + "simulation", + "wallet", + "safety" + ], + "duration": 458, + "language": "en", + "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f", + "sources_youtubeId": "6-ygj7_IqEg", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt", + "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you", + "eventId": "devcon-7", + "slot_start": 1731409800000, + "slot_end": 1731410400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4", + "resources_slides": null, + "speakers": [ + "kim-persson" + ] + }, + "vector": [ + 6, 0, 0, 0, @@ -798153,7 +798954,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -798370,7 +799170,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -798397,7 +799196,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -798421,9 +799219,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -798434,7 +799230,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -798474,6 +799269,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -798495,7 +799291,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -798544,6 +799339,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -798559,6 +799355,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -798843,6 +799640,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -798885,8 +799683,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -798917,11 +799713,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -798934,60 +799728,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "trust-minimized-p2p-marketplaces-on-ethereum", - "sourceId": "YPNBE8", - "title": "Trust-minimized P2P marketplaces on Ethereum", - "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "TLSNotary", - "ZKEmail", - "P2P marketplaces" - ], - "tags": [ - "ZKP", - "Signatures", - "P2P finance", - "p2p", - "marketplace", - "P2P finance", - "Signatures", - "ZKP" - ], - "language": "en", - "speakers": [ - "richard" - ], - "eventId": "devcon-7", - "slot_start": 1731556200000, - "slot_end": 1731556800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -799108,7 +799848,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -799162,9 +799901,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -799177,6 +799918,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "transforming-systems-lessons-from-taiwans-movements", + "sourceId": "B9EDKY", + "title": "Transforming Systems: Lessons from Taiwan's Movements", + "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.", + "track": "Coordination", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Ecosystem", + "Funding", + "Mainstream" + ], + "tags": [ + "Civil Resistance", + "Coordination", + "Public good" + ], + "language": "en", + "speakers": [ + "noah-yeh" + ], + "eventId": "devcon-7", + "slot_start": 1731638700000, + "slot_end": 1731639900000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk" + }, + "vector": [ 0, 0, 0, @@ -799188,6 +799965,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -799789,7 +800567,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -799806,7 +800583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -799852,6 +800628,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -800013,7 +800790,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -800030,6 +800806,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -800075,6 +800852,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -800151,6 +800929,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -800246,8 +801025,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -800276,7 +801053,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -800284,7 +801060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -800293,42 +801068,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created", - "sourceId": "R9ENCP", - "title": "Trust Zones: Why DAOs will be the best organizations ever created", - "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Trust" - ], - "tags": [ - "DAO", - "Governance", - "trusted", - "DAO", - "Governance" - ], - "language": "en", - "speakers": [ - "spencer-graham" - ], - "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731489000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU" - }, - "vector": [ 0, 0, 0, @@ -800340,7 +801079,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -800523,12 +801261,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -800536,6 +801276,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "transitioning-from-an-l1-to-an-l2-a-case-study", + "sourceId": "KHVZ9M", + "title": "Transitioning from an L1 to an L2: A case study", + "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Layer2", + "case study", + "technical learnings" + ], + "tags": [ + "Layer 1", + "Layer 2s", + "Rollups", + "Scalability", + "Optimistic rollups", + "Use Cases", + "learnings", + "technical", + "Layer 1", + "Layer 2s", + "Optimistic rollups", + "Rollups", + "Scalability", + "Use Cases" + ], + "language": "en", + "speakers": [ + "marek-olszewski" + ], + "eventId": "devcon-7", + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg" + }, + "vector": [ 0, 0, 0, @@ -800543,6 +801330,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -801000,7 +801788,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -801075,6 +801862,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -801164,12 +801952,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -801240,7 +802026,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -801296,6 +802081,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -801322,6 +802108,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -801345,7 +802132,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -801356,6 +802145,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -801416,6 +802206,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -801630,11 +802422,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -801647,50 +802437,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "try-it-out-in-remix", - "sourceId": "SUEJQR", - "title": "Try it out in Remix", - "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!", - "track": "Developer Experience", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "AI" - ], - "tags": [ - "Layer 2s", - "Tooling", - "DevRel", - "Desktop", - "ai", - "Desktop", - "DevRel", - "Layer 2s", - "Tooling" - ], - "language": "en", - "speakers": [ - "rob-stupay" - ], - "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -801847,6 +802596,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -801875,9 +802628,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -801890,12 +802645,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "trust-minimized-p2p-marketplaces-on-ethereum", + "sourceId": "YPNBE8", + "title": "Trust-minimized P2P marketplaces on Ethereum", + "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "TLSNotary", + "ZKEmail", + "P2P marketplaces" + ], + "tags": [ + "ZKP", + "Signatures", + "P2P finance", + "p2p", + "marketplace", + "P2P finance", + "Signatures", + "ZKP" + ], + "language": "en", + "speakers": [ + "richard" + ], + "eventId": "devcon-7", + "slot_start": 1731556200000, + "slot_end": 1731556800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -802023,6 +802820,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -802359,7 +803157,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -802447,7 +803244,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -802492,7 +803288,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -802506,7 +803301,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -802600,7 +803394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -802711,6 +803504,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -802727,6 +803521,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -802933,6 +803728,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -802960,7 +803756,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -802990,11 +803785,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -803005,46 +803798,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "txain-discover-the-next-generation-of-blockchain-exploration", - "sourceId": "WRGHRM", - "title": "TXain: Discover the Next Generation of Blockchain Exploration", - "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch", - "track": "Developer Experience", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "blockchain explorer", - "user experience", - "Real-Time Data" - ], - "tags": [ - "data", - "real-time" - ], - "language": "en", - "speakers": [ - "joan-baylina", - "daniel" - ], - "eventId": "devcon-7", - "slot_start": 1731493200000, - "slot_end": 1731493800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -803205,13 +803961,14 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -803234,6 +803991,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -803241,6 +803999,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -803249,6 +804008,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created", + "sourceId": "R9ENCP", + "title": "Trust Zones: Why DAOs will be the best organizations ever created", + "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Trust" + ], + "tags": [ + "DAO", + "Governance", + "trusted", + "DAO", + "Governance" + ], + "language": "en", + "speakers": [ + "spencer-graham" + ], + "eventId": "devcon-7", + "slot_start": 1731488400000, + "slot_end": 1731489000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU" + }, + "vector": [ 0, 0, 0, @@ -803260,6 +804055,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -803714,7 +804510,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -803924,6 +804719,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -804087,6 +804883,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -804162,6 +804959,16 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -804315,7 +805122,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -804344,11 +805150,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -804359,36 +805163,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "txmonster-mud-day-demo", - "sourceId": "3GSMUH", - "title": "TxMonster - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "N/A" - ], - "tags": [], - "language": "en", - "speakers": [ - "buidltxgames" - ], - "eventId": "devcon-7", - "slot_start": 1731558000000, - "slot_end": 1731558300000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM" - }, - "vector": [ 0, 0, 0, @@ -804401,7 +805175,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -804576,9 +805349,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -804591,9 +805366,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "try-it-out-in-remix", + "sourceId": "SUEJQR", + "title": "Try it out in Remix", + "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!", + "track": "Developer Experience", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "AI" + ], + "tags": [ + "Layer 2s", + "Tooling", + "DevRel", + "Desktop", + "ai", + "Desktop", + "DevRel", + "Layer 2s", + "Tooling" + ], + "language": "en", + "speakers": [ + "rob-stupay" + ], + "eventId": "devcon-7", + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -805063,7 +805879,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -805267,6 +806082,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -805354,6 +806170,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -805398,6 +806215,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -805411,6 +806229,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -805504,6 +806323,18 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -805690,11 +806521,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -805707,39 +806536,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "ultimate-dominion-mud-day-demo", - "sourceId": "GPQVMW", - "title": "Ultimate Dominion - MUD Day Demo", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Gaming", - "Autonomous World", - "Autonomous World", - "Gaming" - ], - "language": "en", - "speakers": [ - "ritz-raspa" - ], - "eventId": "devcon-7", - "slot_start": 1731558300000, - "slot_end": 1731558600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU" - }, - "vector": [ 0, 0, 0, @@ -805752,7 +806548,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -805888,6 +806683,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -805917,9 +806713,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -805930,9 +806728,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "txain-discover-the-next-generation-of-blockchain-exploration", + "sourceId": "WRGHRM", + "title": "TXain: Discover the Next Generation of Blockchain Exploration", + "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "blockchain explorer", + "user experience", + "Real-Time Data" + ], + "tags": [ + "data", + "real-time" + ], + "language": "en", + "speakers": [ + "joan-baylina", + "daniel" + ], + "eventId": "devcon-7", + "slot_start": 1731493200000, + "slot_end": 1731493800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -806100,6 +806935,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -806415,7 +807251,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -806589,8 +807424,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -806608,6 +807441,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -806984,6 +807818,9 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, 0, @@ -807043,13 +807880,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -807058,44 +807893,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api", - "sourceId": "VBUJML", - "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API", - "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "none" - ], - "tags": [ - "Coordination", - "Decentralization", - "Ethereum for Good", - "Coordination", - "Decentralization", - "Ethereum for Good" - ], - "language": "en", - "speakers": [ - "thomas-jay-rush", - "meriam-zandi" - ], - "eventId": "devcon-7", - "slot_start": 1731492000000, - "slot_end": 1731492600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0" - }, - "vector": [ 0, 0, 0, @@ -807107,7 +807904,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -807246,6 +808042,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -807274,9 +808071,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -807287,6 +808086,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "txmonster-mud-day-demo", + "sourceId": "3GSMUH", + "title": "TxMonster - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "N/A" + ], + "tags": [], + "language": "en", + "speakers": [ + "buidltxgames" + ], + "eventId": "devcon-7", + "slot_start": 1731558000000, + "slot_end": 1731558300000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM" + }, + "vector": [ 0, 0, 0, @@ -807299,6 +808128,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -807772,8 +808602,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -807937,7 +808765,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -807961,13 +808788,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -807990,7 +808817,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -808397,80 +809223,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "understanding-eip-7002-and-eip-6110", - "sourceId": "KPD8HB", - "title": "Understanding EIP-7002 and EIP-6110", - "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Staking" - ], - "keywords": [ - "EIP", - "validator", - "staking" - ], - "duration": 1495, - "language": "en", - "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34", - "sources_youtubeId": "EyDChjFQEkQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt", - "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.", - "eventId": "devcon-7", - "slot_start": 1731396600000, - "slot_end": 1731398400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0", - "resources_slides": null, - "speakers": [ - "lucas-saldanha", - "stefan-bratanov" - ] - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -808669,9 +809421,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -808684,6 +809438,39 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "ultimate-dominion-mud-day-demo", + "sourceId": "GPQVMW", + "title": "Ultimate Dominion - MUD Day Demo", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Gaming", + "Autonomous World", + "Autonomous World", + "Gaming" + ], + "language": "en", + "speakers": [ + "ritz-raspa" + ], + "eventId": "devcon-7", + "slot_start": 1731558300000, + "slot_end": 1731558600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU" + }, + "vector": [ 0, 0, 0, @@ -808696,6 +809483,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -809136,8 +809924,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -809326,7 +810112,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -809365,6 +810150,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -809538,6 +810324,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -809759,11 +810547,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -809776,51 +810562,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both", - "sourceId": "HZCDFP", - "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?", - "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?", - "track": "Layer 2", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ERC-7683", - "Interoperability", - "Unified-Ethereum" - ], - "tags": [ - "Cross-L2", - "UI/UX", - "Intents", - "ethereum", - "unified", - "Cross-L2", - "Intents", - "UI/UX" - ], - "language": "en", - "speakers": [ - "hart-lambur", - "ben-jones", - "vitalik-buterin", - "steven-goldfeder", - "jesse-pollak" - ], - "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731483000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y" - }, - "vector": [ 0, 0, 0, @@ -809828,7 +810569,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -810015,7 +810755,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -810039,11 +810778,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -810052,6 +810793,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api", + "sourceId": "VBUJML", + "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API", + "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "none" + ], + "tags": [ + "Coordination", + "Decentralization", + "Ethereum for Good", + "Coordination", + "Decentralization", + "Ethereum for Good" + ], + "language": "en", + "speakers": [ + "thomas-jay-rush", + "meriam-zandi" + ], + "eventId": "devcon-7", + "slot_start": 1731492000000, + "slot_end": 1731492600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0" + }, + "vector": [ 0, 0, 0, @@ -810063,6 +810842,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -810257,7 +811037,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -810320,7 +811099,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -810501,8 +811279,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -810615,11 +811391,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -810737,6 +811511,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -810762,7 +811538,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -810868,7 +811643,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -810902,6 +811676,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -810925,6 +811700,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -810953,6 +811729,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811096,7 +811873,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811122,7 +811898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811130,7 +811905,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811139,46 +811913,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure", - "sourceId": "NX7U8B", - "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure", - "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ENS" - ], - "tags": [ - "ens", - "Accessibility", - "Public good", - "Use cases of cryptography" - ], - "language": "en", - "speakers": [ - "estmcmxcieth" - ], - "eventId": "devcon-7", - "slot_start": 1731467100000, - "slot_end": 1731467700000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -811398,6 +812136,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811406,6 +812145,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -811413,10 +812153,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "understanding-eip-7002-and-eip-6110", + "sourceId": "KPD8HB", + "title": "Understanding EIP-7002 and EIP-6110", + "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Staking" + ], + "keywords": [ + "EIP", + "validator", + "staking" + ], + "duration": 1495, + "language": "en", + "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34", + "sources_youtubeId": "EyDChjFQEkQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt", + "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.", + "eventId": "devcon-7", + "slot_start": 1731396600000, + "slot_end": 1731398400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0", + "resources_slides": null, + "speakers": [ + "lucas-saldanha", + "stefan-bratanov" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -811856,7 +812641,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -811941,7 +812725,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -811973,7 +812756,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812022,7 +812804,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812098,6 +812879,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -812286,6 +813069,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -812450,7 +813234,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -812475,12 +813258,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -812492,46 +813273,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop", - "sourceId": "VPMQGM", - "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop", - "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.", - "track": "Applied Cryptography", - "type": "Workshop", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "oracle" - ], - "tags": [ - "Live Coding", - "Privacy", - "MPC", - "oracle", - "Live Coding", - "MPC", - "Privacy" - ], - "language": "en", - "speakers": [ - "hendrik-eeckhaut", - "sinu", - "tsukino" - ], - "eventId": "devcon-7", - "slot_start": 1731577200000, - "slot_end": 1731582600000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0" - }, - "vector": [ 0, 0, 0, @@ -812542,8 +813283,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -812763,9 +813502,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -812778,6 +813519,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both", + "sourceId": "HZCDFP", + "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?", + "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?", + "track": "Layer 2", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ERC-7683", + "Interoperability", + "Unified-Ethereum" + ], + "tags": [ + "Cross-L2", + "UI/UX", + "Intents", + "ethereum", + "unified", + "Cross-L2", + "Intents", + "UI/UX" + ], + "language": "en", + "speakers": [ + "hart-lambur", + "ben-jones", + "vitalik-buterin", + "steven-goldfeder", + "jesse-pollak" + ], + "eventId": "devcon-7", + "slot_start": 1731479400000, + "slot_end": 1731483000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y" + }, + "vector": [ 0, 0, 0, @@ -812785,6 +813571,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -812972,6 +813759,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -813196,7 +813984,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -813216,7 +814003,6 @@ 0, 0, 6, - 6, 0, 0, 0, @@ -813279,6 +814065,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -813360,7 +814154,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -813387,8 +814180,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -813457,6 +814248,10 @@ 0, 0, 0, + 6, + 6, + 0, + 0, 0, 0, 0, @@ -813567,6 +814362,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -813815,6 +814615,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -813833,13 +814635,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -813850,40 +814650,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2", - "sourceId": "NGZBJL", - "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2", - "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Developper", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Privacy", - "Scalability", - "Statelessness" - ], - "tags": [ - "statelessness" - ], - "language": "en", - "speakers": [ - "leona-hioki" - ], - "eventId": "devcon-7", - "slot_start": 1731495600000, - "slot_end": 1731497400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ" - }, - "vector": [ 0, 0, 0, @@ -813891,7 +814657,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -814078,6 +814843,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -814100,6 +814869,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -814107,6 +814877,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -814115,10 +814886,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure", + "sourceId": "NX7U8B", + "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure", + "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ENS" + ], + "tags": [ + "ens", + "Accessibility", + "Public good", + "Use cases of cryptography" + ], + "language": "en", + "speakers": [ + "estmcmxcieth" + ], + "eventId": "devcon-7", + "slot_start": 1731467100000, + "slot_end": 1731467700000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -814569,7 +815376,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -814801,6 +815607,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -814885,6 +815692,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -814916,6 +815724,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -814964,6 +815773,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -815148,7 +815958,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -815185,75 +815994,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities", - "sourceId": "N3JJFU", - "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities", - "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [ - "DeFi" - ], - "tags": [ - "Regulation", - "UI/UX", - "Account Abstraction", - "Economics", - "defi", - "Account Abstraction", - "Economics", - "Regulation", - "UI/UX" - ], - "language": "en", - "speakers": [ - "charles-st-louis" - ], - "eventId": "devcon-7", - "slot_start": 1731580800000, - "slot_end": 1731581400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -815461,6 +816201,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -815485,10 +816226,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -815500,6 +816243,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop", + "sourceId": "VPMQGM", + "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop", + "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.", + "track": "Applied Cryptography", + "type": "Workshop", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "oracle" + ], + "tags": [ + "Live Coding", + "Privacy", + "MPC", + "oracle", + "Live Coding", + "MPC", + "Privacy" + ], + "language": "en", + "speakers": [ + "hendrik-eeckhaut", + "sinu", + "tsukino" + ], + "eventId": "devcon-7", + "slot_start": 1731577200000, + "slot_end": 1731582600000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0" + }, + "vector": [ 0, 0, 0, @@ -815510,6 +816293,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -815928,7 +816712,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -816016,7 +816799,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -816032,7 +816814,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -816040,7 +816821,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -816088,7 +816868,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -816172,9 +816951,9 @@ 0, 0, 0, + 6, 0, 0, - 2, 0, 0, 0, @@ -816191,6 +816970,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -816334,6 +817115,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816360,6 +817142,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -816545,13 +817329,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -816560,52 +817342,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling", - "sourceId": "87XNSS", - "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling", - "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EOF", - "EIP-7692", - "EVM" - ], - "tags": [ - "Core Protocol", - "Developer Infrastructure", - "DevEx", - "EVM", - "Core Protocol", - "Developer Infrastructure", - "DevEx" - ], - "language": "en", - "speakers": [ - "nebojsa-urosevic", - "pavle-drobnjak" - ], - "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731562800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -816724,6 +817464,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -816847,11 +817588,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -816862,6 +817605,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2", + "sourceId": "NGZBJL", + "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2", + "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Developper", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Privacy", + "Scalability", + "Statelessness" + ], + "tags": [ + "statelessness" + ], + "language": "en", + "speakers": [ + "leona-hioki" + ], + "eventId": "devcon-7", + "slot_start": 1731495600000, + "slot_end": 1731497400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ" + }, + "vector": [ 0, 0, 0, @@ -816869,6 +817646,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -817288,8 +818066,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -817359,7 +818135,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -817370,7 +818145,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -817394,7 +818168,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -817549,13 +818322,13 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -817902,11 +818675,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -817919,51 +818690,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks", - "sourceId": "TZVK7F", - "title": "Updating Gas Cost Schedule based on reproducible benchmarks", - "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Gas Cost Schedule", - "EVM Internals", - "Client Diversity", - "Node Infrastructure" - ], - "tags": [ - "Gas", - "Decentralization", - "infrastructure", - "node", - "Decentralization", - "Gas" - ], - "language": "en", - "speakers": [ - "jacek-glen" - ], - "eventId": "devcon-7", - "slot_start": 1731572400000, - "slot_end": 1731573000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -818177,6 +818907,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -818213,6 +818944,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -818224,16 +818956,58 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities", + "sourceId": "N3JJFU", + "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities", + "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [ + "DeFi" + ], + "tags": [ + "Regulation", + "UI/UX", + "Account Abstraction", + "Economics", + "defi", + "Account Abstraction", + "Economics", + "Regulation", + "UI/UX" + ], + "language": "en", + "speakers": [ + "charles-st-louis" + ], + "eventId": "devcon-7", + "slot_start": 1731580800000, + "slot_end": 1731581400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -818648,7 +819422,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -818770,7 +819543,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -818800,7 +819572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -818886,7 +819657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -818921,6 +819691,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -818928,7 +819699,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -819009,6 +819779,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -819024,6 +819795,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -819031,6 +819803,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -819078,6 +819851,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -819163,6 +819937,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -819260,7 +820039,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -819269,7 +820047,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -819277,42 +820054,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "usc-ultimate-solidity-championship", - "sourceId": "UE8WVS", - "title": "USC Ultimate Solidity Championship", - "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.", - "track": "Entertainment", - "type": "Mixed Formats", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Solidity", - "Programming", - "Competition" - ], - "tags": [ - "Art", - "Hacks", - "Public good" - ], - "language": "en", - "speakers": [ - "five" - ], - "eventId": "devcon-7", - "slot_start": 1731582000000, - "slot_end": 1731583800000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU" - }, - "vector": [ 0, 0, 0, @@ -819322,7 +820063,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -819568,6 +820308,14 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, @@ -819575,6 +820323,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling", + "sourceId": "87XNSS", + "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling", + "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EOF", + "EIP-7692", + "EVM" + ], + "tags": [ + "Core Protocol", + "Developer Infrastructure", + "DevEx", + "EVM", + "Core Protocol", + "Developer Infrastructure", + "DevEx" + ], + "language": "en", + "speakers": [ + "nebojsa-urosevic", + "pavle-drobnjak" + ], + "eventId": "devcon-7", + "slot_start": 1731562200000, + "slot_end": 1731562800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, 0, 0, 0, @@ -820160,8 +820956,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -820261,6 +821055,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -820304,7 +821100,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -820331,6 +821126,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -820341,6 +821137,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -820364,6 +821161,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -820518,6 +821316,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -820616,9 +821415,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -820631,51 +821428,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "using-reth-execution-extensions-for-next-generation-indexing", - "sourceId": "YUFRTQ", - "title": "Using Reth Execution Extensions for next generation indexing", - "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "client", - "plugin", - "indexer" - ], - "tags": [ - "Layer 1", - "Developer Infrastructure", - "Tooling", - "plugin", - "Developer Infrastructure", - "Layer 1", - "Tooling" - ], - "language": "en", - "speakers": [ - "alexey-shekhirin" - ], - "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -820913,9 +821669,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -820928,10 +821686,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks", + "sourceId": "TZVK7F", + "title": "Updating Gas Cost Schedule based on reproducible benchmarks", + "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Gas Cost Schedule", + "EVM Internals", + "Client Diversity", + "Node Infrastructure" + ], + "tags": [ + "Gas", + "Decentralization", + "infrastructure", + "node", + "Decentralization", + "Gas" + ], + "language": "en", + "speakers": [ + "jacek-glen" + ], + "eventId": "devcon-7", + "slot_start": 1731572400000, + "slot_end": 1731573000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -821361,7 +822160,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -821425,13 +822223,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -821464,7 +822260,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -821624,6 +822419,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -821745,6 +822541,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -821774,6 +822571,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -821859,6 +822657,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -821900,6 +822699,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -821948,7 +822748,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -821972,11 +822771,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -821989,61 +822786,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "utilizing-national-ids-in-the-ethereum-ecosystem", - "sourceId": "PR78EL", - "title": "Utilizing national IDs in the Ethereum ecosystem", - "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "National IDs", - "Selective Disclosure" - ], - "tags": [ - "Civil Resistance", - "Privacy", - "Identity", - "Civil Resistance", - "Identity", - "Privacy" - ], - "language": "en", - "speakers": [ - "yanis", - "michael-elliot", - "hiroyuki-tachibana", - "florent", - "nico" - ], - "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731555900000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -822140,10 +822882,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, 0, 0, 0, @@ -822205,28 +822943,6 @@ 0, 0, 0, - 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -822315,6 +823031,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -822323,6 +823040,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -822330,6 +823048,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "usc-ultimate-solidity-championship", + "sourceId": "UE8WVS", + "title": "USC Ultimate Solidity Championship", + "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.", + "track": "Entertainment", + "type": "Mixed Formats", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Solidity", + "Programming", + "Competition" + ], + "tags": [ + "Art", + "Hacks", + "Public good" + ], + "language": "en", + "speakers": [ + "five" + ], + "eventId": "devcon-7", + "slot_start": 1731582000000, + "slot_end": 1731583800000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU" + }, + "vector": [ 0, 0, 0, @@ -822339,6 +823093,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -822722,8 +823477,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -822819,7 +823572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -822887,7 +823639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -823002,7 +823753,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -823185,6 +823935,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -823327,16 +824079,15 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -823349,41 +824100,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "vadcops-leveraging-starks-for-tailored-proof-generation", - "sourceId": "BEJPG8", - "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation", - "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "STARKs", - "VADCOPs", - "" - ], - "tags": [ - "vadcops" - ], - "language": "en", - "speakers": [ - "hector-masip-ardevol", - "felicia-barcelo" - ], - "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0" - }, - "vector": [ 0, 0, 0, @@ -823394,7 +824110,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -823676,7 +824391,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -823689,10 +824406,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "using-reth-execution-extensions-for-next-generation-indexing", + "sourceId": "YUFRTQ", + "title": "Using Reth Execution Extensions for next generation indexing", + "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "client", + "plugin", + "indexer" + ], + "tags": [ + "Layer 1", + "Developer Infrastructure", + "Tooling", + "plugin", + "Developer Infrastructure", + "Layer 1", + "Tooling" + ], + "language": "en", + "speakers": [ + "alexey-shekhirin" + ], + "eventId": "devcon-7", + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -824077,8 +824835,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -824384,6 +825140,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -824447,11 +825204,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -824484,6 +825243,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -824662,7 +825422,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -824685,11 +825444,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -824702,56 +825459,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "verifier-alliance-inside-of-the-contract-verification-pipeline", - "sourceId": "Q3EDF8", - "title": "Verifier Alliance: inside of the contract verification pipeline", - "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).", - "track": "Developer Experience", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Contract", - "Verification" - ], - "tags": [ - "DevEx", - "verification", - "contracts", - "DevEx" - ], - "language": "en", - "speakers": [ - "rim-rakhimov" - ], - "eventId": "devcon-7", - "slot_start": 1731472800000, - "slot_end": 1731473400000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ" - }, - "vector": [ - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -825020,6 +825727,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -825043,9 +825751,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -825058,12 +825768,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "utilizing-national-ids-in-the-ethereum-ecosystem", + "sourceId": "PR78EL", + "title": "Utilizing national IDs in the Ethereum ecosystem", + "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "National IDs", + "Selective Disclosure" + ], + "tags": [ + "Civil Resistance", + "Privacy", + "Identity", + "Civil Resistance", + "Identity", + "Privacy" + ], + "language": "en", + "speakers": [ + "yanis", + "michael-elliot", + "hiroyuki-tachibana", + "florent", + "nico" + ], + "eventId": "devcon-7", + "slot_start": 1731552300000, + "slot_end": 1731555900000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -825167,6 +825920,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -825231,6 +825985,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -825433,7 +826189,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -825507,7 +826262,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -825738,7 +826492,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -825752,6 +826505,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -825847,6 +826602,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -825899,7 +826655,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -825915,6 +826670,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -826029,6 +826785,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -826039,13 +826796,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -826056,42 +826811,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "verkle-integration-in-reth", - "sourceId": "T8LKTM", - "title": "Verkle integration in reth", - "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.", - "track": "[CLS] EPF Day", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Stateless clients", - "Verge" - ], - "tags": [ - "EPF", - "Core Protocol", - "Cryptography", - "Verkle trees" - ], - "language": "en", - "speakers": [ - "aditya-gupta" - ], - "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731473100000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI" - }, - "vector": [ 0, 0, 0, @@ -826107,7 +826826,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -826397,9 +827115,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -826412,6 +827132,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "vadcops-leveraging-starks-for-tailored-proof-generation", + "sourceId": "BEJPG8", + "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation", + "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "STARKs", + "VADCOPs", + "" + ], + "tags": [ + "vadcops" + ], + "language": "en", + "speakers": [ + "hector-masip-ardevol", + "felicia-barcelo" + ], + "eventId": "devcon-7", + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0" + }, + "vector": [ 0, 0, 0, @@ -826422,6 +827177,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -826788,7 +827544,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -826844,13 +827599,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -827026,7 +827779,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -827112,6 +827864,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -827135,7 +827889,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -827393,12 +828146,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -827410,36 +828161,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "viruses-and-chronic-aging-building-a-research-community", - "sourceId": "FX8UQF", - "title": "Viruses and Chronic Aging: Building a Research Community", - "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "amy-proal" - ], - "eventId": "devcon-7", - "slot_start": 1731572700000, - "slot_end": 1731573600000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -827727,6 +828449,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -827749,9 +828472,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -827764,9 +828489,46 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "verifier-alliance-inside-of-the-contract-verification-pipeline", + "sourceId": "Q3EDF8", + "title": "Verifier Alliance: inside of the contract verification pipeline", + "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).", + "track": "Developer Experience", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Contract", + "Verification" + ], + "tags": [ + "DevEx", + "verification", + "contracts", + "DevEx" + ], + "language": "en", + "speakers": [ + "rim-rakhimov" + ], + "eventId": "devcon-7", + "slot_start": 1731472800000, + "slot_end": 1731473400000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -828135,7 +828897,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -828463,6 +829224,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -828536,6 +829298,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -828739,7 +829502,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -828748,7 +829510,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -828756,36 +829517,7 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "visions-of-a-viable-dacc-biosafety-strategy", - "sourceId": "7VDGQM", - "title": "Visions of a Viable d/acc Biosafety Strategy", - "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", - "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", - "type": "Lightning Talk", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "vitalik-buterin" - ], - "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731567900000, - "slot_roomId": "breakout-3", - "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko" - }, - "vector": [ 0, - 6, 0, 0, 0, @@ -828797,6 +829529,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -828957,6 +829690,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -828978,23 +829712,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -829113,11 +829830,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -829128,6 +829847,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "verkle-integration-in-reth", + "sourceId": "T8LKTM", + "title": "Verkle integration in reth", + "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.", + "track": "[CLS] EPF Day", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Stateless clients", + "Verge" + ], + "tags": [ + "EPF", + "Core Protocol", + "Cryptography", + "Verkle trees" + ], + "language": "en", + "speakers": [ + "aditya-gupta" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731473100000, + "slot_roomId": "breakout-1", + "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI" + }, + "vector": [ 0, 0, 0, @@ -829143,6 +829898,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -829827,6 +830583,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -829882,11 +830639,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -830062,6 +830821,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -830086,10 +830846,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -830102,52 +830860,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption", - "sourceId": "ZAYEXK", - "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption", - "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "culture", - "aesthetics", - "communication" - ], - "tags": [ - "Coordination", - "Identity", - "Design", - "communication", - "Coordination", - "Design", - "Identity" - ], - "language": "en", - "speakers": [ - "ira-nezhynska" - ], - "eventId": "devcon-7", - "slot_start": 1731495000000, - "slot_end": 1731495600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -830213,6 +830930,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -830470,10 +831188,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -830485,7 +831205,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "viruses-and-chronic-aging-building-a-research-community", + "sourceId": "FX8UQF", + "title": "Viruses and Chronic Aging: Building a Research Community", + "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "amy-proal" + ], + "eventId": "devcon-7", + "slot_start": 1731572700000, + "slot_end": 1731573600000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -830840,7 +831589,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -830930,7 +831678,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -831024,7 +831771,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -831036,7 +831782,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -831143,7 +831888,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -831190,6 +831934,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -831445,14 +832190,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -831460,49 +832203,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "vlsmsanalyzing-faulty-distributed-systems", - "sourceId": "AKRLKH", - "title": "VLSMs—analyzing faulty distributed systems", - "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Correct-by-construction" - ], - "tags": [ - "Consensus", - "Distributed validator technology", - "Formal Verification", - "correct-by-construction", - "Consensus", - "Distributed validator technology", - "Formal Verification" - ], - "language": "en", - "speakers": [ - "vlad-zamfir" - ], - "eventId": "devcon-7", - "slot_start": 1731552300000, - "slot_end": 1731554100000, - "slot_roomId": "classroom-d", - "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -831834,6 +832538,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -831842,6 +832547,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -831849,7 +832555,36 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "visions-of-a-viable-dacc-biosafety-strategy", + "sourceId": "7VDGQM", + "title": "Visions of a Viable d/acc Biosafety Strategy", + "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.", + "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia", + "type": "Lightning Talk", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "vitalik-buterin" + ], + "eventId": "devcon-7", + "slot_start": 1731567600000, + "slot_end": 1731567900000, + "slot_roomId": "breakout-3", + "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko" + }, + "vector": [ 0, + 6, 0, 0, 0, @@ -832043,6 +832778,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -832197,7 +832933,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -832242,7 +832977,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -832436,7 +833170,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -832704,7 +833437,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -832777,7 +833509,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -832802,9 +833533,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -832816,51 +833545,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "voices-of-tech-and-open-source-movement-across-asia", - "sourceId": "QCPSDK", - "title": "Voices of Tech & Open Source Movement Across Asia", - "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.", - "track": "Cypherpunk & Privacy", - "type": "Panel", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "FOSS", - "Regional", - "Insights" - ], - "tags": [ - "FOSS", - "regional", - "insights" - ], - "language": "en", - "speakers": [ - "hong-phuc-dang", - "mario-behling", - "brianna-chang", - "mishari-muqbil" - ], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731472200000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU" - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -833200,8 +833889,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -833214,11 +833905,52 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption", + "sourceId": "ZAYEXK", + "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption", + "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "culture", + "aesthetics", + "communication" + ], + "tags": [ + "Coordination", + "Identity", + "Design", + "communication", + "Coordination", + "Design", + "Identity" + ], + "language": "en", + "speakers": [ + "ira-nezhynska" + ], + "eventId": "devcon-7", + "slot_start": 1731495000000, + "slot_end": 1731495600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -833555,10 +834287,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -833919,6 +834647,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -833928,7 +834657,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -834009,6 +834737,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834102,6 +834831,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834113,6 +834843,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834135,8 +834866,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -834158,9 +834887,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -834173,45 +834900,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "voting-with-time-commitment", - "sourceId": "7V7QNK", - "title": "Voting with time commitment", - "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Voting" - ], - "tags": [ - "Governance", - "Mechanism design", - "voting", - "Governance", - "Mechanism design" - ], - "language": "en", - "speakers": [ - "vijay-mohan" - ], - "eventId": "devcon-7", - "slot_start": 1731489600000, - "slot_end": 1731491400000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -834260,6 +834950,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -834561,12 +835252,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -834574,10 +835267,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "vlsmsanalyzing-faulty-distributed-systems", + "sourceId": "AKRLKH", + "title": "VLSMs—analyzing faulty distributed systems", + "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Correct-by-construction" + ], + "tags": [ + "Consensus", + "Distributed validator technology", + "Formal Verification", + "correct-by-construction", + "Consensus", + "Distributed validator technology", + "Formal Verification" + ], + "language": "en", + "speakers": [ + "vlad-zamfir" + ], + "eventId": "devcon-7", + "slot_start": 1731552300000, + "slot_end": 1731554100000, + "slot_roomId": "classroom-d", + "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8" + }, + "vector": [ 0, 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -834913,7 +835646,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -834955,7 +835687,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -835044,7 +835775,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -835278,6 +836008,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -835309,7 +836040,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -835323,6 +836053,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -835510,7 +836244,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -835527,47 +836260,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wallet-infra-101-and-where-innovation-needs-to-happen", - "sourceId": "RQAAFS", - "title": "Wallet Infra 101, & where innovation needs to happen", - "description": "In this talk I hope to go over the infrastructure stack of a standard wallet, and then also go into where in this stack I think innovation should happen/is already happening and why that's exciting. This will also broadly cover other related topics such as: \r\n- The future state of crypto UI & dapp interactions\r\n- What crypto wallets can learn from web2 apps \r\n- My framework around \"What users can do with their balance?\", and how wallets can use that to build new features", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "wallet", - "dapps", - "" - ], - "tags": [ - "Accessibility", - "Account Abstraction", - "Architecture", - "Frameworks", - "Gas", - "Intents", - "Payment", - "UI/UX" - ], - "language": "en", - "speakers": [ - "medha-kothari" - ], - "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731559200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k" - }, - "vector": [ 0, 0, 0, @@ -835576,7 +836268,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -835824,6 +836515,19 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -835884,6 +836588,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -835908,7 +836613,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -835920,11 +836627,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "voices-of-tech-and-open-source-movement-across-asia", + "sourceId": "QCPSDK", + "title": "Voices of Tech & Open Source Movement Across Asia", + "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.", + "track": "Cypherpunk & Privacy", + "type": "Panel", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "FOSS", + "Regional", + "Insights" + ], + "tags": [ + "FOSS", + "regional", + "insights" + ], + "language": "en", + "speakers": [ + "hong-phuc-dang", + "mario-behling", + "brianna-chang", + "mishari-muqbil" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731472200000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU" + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -836273,7 +837020,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -836358,18 +837104,13 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, - 2, - 2, 0, - 2, 0, 0, 0, @@ -836412,7 +837153,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -836448,7 +837188,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -836537,7 +837276,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -836632,6 +837370,10 @@ 0, 0, 0, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -836871,9 +837613,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -836886,68 +837626,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wallet-ux-panel", - "sourceId": "9HACGK", - "title": "Wallet UX Panel", - "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.", - "track": "Usability", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Wallets", - "User Experience", - "Standards" - ], - "tags": [ - "Coordination", - "Custody", - "Account Abstraction", - "standards", - "Account Abstraction", - "Coordination", - "Custody" - ], - "language": "en", - "speakers": [ - "lukas-schor", - "derek-rein", - "arik-galansky", - "adam-ceresko", - "chintan-turakhia" - ], - "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731475800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -837065,6 +837743,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -837271,6 +837950,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -837292,7 +837973,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -837305,8 +837988,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "voting-with-time-commitment", + "sourceId": "7V7QNK", + "title": "Voting with time commitment", + "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Voting" + ], + "tags": [ + "Governance", + "Mechanism design", + "voting", + "Governance", + "Mechanism design" + ], + "language": "en", + "speakers": [ + "vijay-mohan" + ], + "eventId": "devcon-7", + "slot_start": 1731489600000, + "slot_end": 1731491400000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -837636,11 +838356,6 @@ 0, 0, 0, - 6, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -837720,7 +838435,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -837814,7 +838528,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -837824,7 +838537,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -838020,6 +838732,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -838061,6 +838774,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -838233,65 +838947,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "warren-winter", - "sourceId": "9PWLDW", - "title": "Warren Winter", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731577500000, - "slot_end": 1731580200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -838473,6 +839128,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -838673,9 +839329,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -838688,6 +839346,47 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wallet-infra-101-and-where-innovation-needs-to-happen", + "sourceId": "RQAAFS", + "title": "Wallet Infra 101, & where innovation needs to happen", + "description": "In this talk I hope to go over the infrastructure stack of a standard wallet, and then also go into where in this stack I think innovation should happen/is already happening and why that's exciting. This will also broadly cover other related topics such as: \r\n- The future state of crypto UI & dapp interactions\r\n- What crypto wallets can learn from web2 apps \r\n- My framework around \"What users can do with their balance?\", and how wallets can use that to build new features", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "wallet", + "dapps", + "" + ], + "tags": [ + "Accessibility", + "Account Abstraction", + "Architecture", + "Frameworks", + "Gas", + "Intents", + "Payment", + "UI/UX" + ], + "language": "en", + "speakers": [ + "medha-kothari" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731559200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k" + }, + "vector": [ 0, 0, 0, @@ -838696,6 +839395,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -839396,6 +840096,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -839480,13 +840181,18 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, + 2, + 2, 0, + 2, 0, 0, 0, @@ -839529,6 +840235,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -839564,6 +840271,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -839576,10 +840284,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -839592,32 +840298,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "web3-poetry-day-1", - "sourceId": "VDMFMR", - "title": "Web3 Poetry - Day 1", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731402000000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA" - }, - "vector": [ 0, 0, 0, @@ -839627,7 +840307,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -839681,6 +840360,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -840014,7 +840694,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -840027,6 +840709,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wallet-ux-panel", + "sourceId": "9HACGK", + "title": "Wallet UX Panel", + "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.", + "track": "Usability", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Wallets", + "User Experience", + "Standards" + ], + "tags": [ + "Coordination", + "Custody", + "Account Abstraction", + "standards", + "Account Abstraction", + "Coordination", + "Custody" + ], + "language": "en", + "speakers": [ + "lukas-schor", + "derek-rein", + "arik-galansky", + "adam-ceresko", + "chintan-turakhia" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731475800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew" + }, + "vector": [ 0, 0, 0, @@ -840035,6 +840761,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -840736,6 +841463,11 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 6, 0, 0, 0, @@ -840815,6 +841547,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -840908,6 +841641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -840917,13 +841651,12 @@ 0, 0, 0, + 2, 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -840936,32 +841669,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "web3-poetry-day-3", - "sourceId": "GN8LTB", - "title": "Web3 Poetry - Day 3", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731571200000, - "slot_end": 1731574800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY" - }, - "vector": [ 0, 0, 0, @@ -840971,7 +841678,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -841270,6 +841976,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -841353,12 +842060,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -841366,6 +842075,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "warren-winter", + "sourceId": "9PWLDW", + "title": "Warren Winter", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731577500000, + "slot_end": 1731580200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ" + }, + "vector": [ 0, 0, 0, @@ -841375,6 +842110,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -842264,10 +843000,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -842280,32 +843014,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "web3-poetry-jam", - "sourceId": "V79DXK", - "title": "Web3 Poetry Jam", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731484800000, - "slot_end": 1731486600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY" - }, - "vector": [ 0, 0, 0, @@ -842315,7 +843023,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -842700,8 +843407,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -842714,6 +843423,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "web3-poetry-day-1", + "sourceId": "VDMFMR", + "title": "Web3 Poetry - Day 1", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731398400000, + "slot_end": 1731402000000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA" + }, + "vector": [ 0, 0, 0, @@ -842723,6 +843458,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -843608,10 +844344,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -843624,42 +844358,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "web3-security-is-embarrasing", - "sourceId": "VNFNDM", - "title": "Web3 Security is Embarrasing", - "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "phishing", - "protection" - ], - "tags": [ - "Security", - "Sustainability", - "User Experience" - ], - "language": "en", - "speakers": [ - "andrew-macpherson" - ], - "eventId": "devcon-7", - "slot_start": 1731573000000, - "slot_end": 1731574800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM" - }, - "vector": [ - 6, 0, 0, 0, @@ -844057,6 +844755,60 @@ 0, 0, 0, + 2, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "web3-poetry-day-3", + "sourceId": "GN8LTB", + "title": "Web3 Poetry - Day 3", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731571200000, + "slot_end": 1731574800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, 0, 0, 0, @@ -844370,7 +845122,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844398,7 +845149,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844414,7 +845164,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -844748,7 +845497,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -844960,11 +845708,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -844977,49 +845723,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "web3-user-research-101", - "sourceId": "7YZGVW", - "title": "Web3 User Research 101", - "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.", - "track": "Usability", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Design", - "featured": true, - "doNotRecord": false, - "keywords": [ - "101" - ], - "tags": [ - "Best Practices", - "User Experience", - "UI/UX", - "User Research", - "Design Thinking", - "101", - "Best Practices", - "Design Thinking", - "UI/UX", - "User Experience", - "User Research" - ], - "language": "en", - "speakers": [ - "mindy-harrell", - "kristina-mayman" - ], - "eventId": "devcon-7", - "slot_start": 1731398400000, - "slot_end": 1731405600000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y" - }, - "vector": [ 0, 0, 0, @@ -845028,7 +845731,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -845401,8 +846103,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -845415,6 +846119,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "web3-poetry-jam", + "sourceId": "V79DXK", + "title": "Web3 Poetry Jam", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731484800000, + "slot_end": 1731486600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY" + }, + "vector": [ 0, 0, 0, @@ -845424,6 +846154,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -845732,8 +846463,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -845775,7 +846504,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -845790,7 +846518,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -845818,7 +846545,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -845846,7 +846572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -845903,7 +846628,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -846302,7 +847026,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -846323,7 +847046,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -846336,64 +847058,13 @@ 0, 0, 0, - 2, 0, - 0 - ] - }, - { - "session": { - "id": "wen-p2p-electronic-cash-system", - "sourceId": "ZFX3ZF", - "title": "Wen p2p Electronic Cash System?", - "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).", - "track": "Real World Ethereum", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "tags": [ - "Conviction", - "Payment", - "Account Abstraction", - "stablecoin", - "Account Abstraction", - "Conviction", - "Payment" - ], - "keywords": [ - "payments", - "cash", - "stablecoins" - ], - "duration": 1549, - "language": "en", - "sources_swarmHash": "", - "sources_youtubeId": "7JFFfcT1yzI", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673321cc3a168eb53554b6fe.vtt", - "transcript_text": " Hello. Hello. Cool. Who knows in which year the peer-to-peer electronic cash system paper came out? Anyone else? I'm sure you know. Just three people? Four people? Okay, which year was it? 2008, right? So we're still waiting for that peer-to-peer electronic cash. I think it's fair to say that we've not taken over the peer-to-peer payments world. Bitcoin has definitely found PMF product market fit with store of value. And I don't want to argue that there are no payments on Bitcoin. But clearly, the last payments you've made to come here, maybe with your Grab or Bolt or Uber were probably not Bitcoin or on-chain payments at all. Just to show how ancient this paper is, this is 2008, right? So in 2008, GTA 4 came out. That's how long ago this was. The iPhone just came out a year earlier. People dressed like this. I think it's cool, but also very, very ancient. Bitcoin was largely, well, came out right in time as a perfect reaction to the financial crisis of 2007-2008. This is how long ago it was. a perfect reaction to the financial crisis of 2007-8. This is how long ago it was. I think we all here know what peer-to-peer means, but let's briefly talk about the cash part, because I think it's very easy to think of cash as payments. But payments are not exactly cash. I would say that cash payments are a subset of all payments. And usually when we talk about payments, we talk about something that's much, much more complicated. So last time you ordered your Grab to get here, you made probably a credit card payment. With that there was a very big bundle of services that enabled things like chargebacks, maybe you were using a credit card and definitely there are some points and rewards so I'm still waiting for the visa and MasterCard airdrop. But I would just want to talk about the simplest of payments like this very raw payment which just goes payer to payee without all of these bundled services. So this is what we usually mean by cash payment, right? Like if I give 100 baht to a taxi driver, there's no way to charge back unless I hunt him down somehow. There are also no points and there's definitely not a credit system. So for today, I'd briefly like to talk about why we haven't taken over the world yet and what's needed to take over the world with on-chain payments. So I'll give a mini intro about myself and then we'll go through a mini history just to honor our ancestors. And then I'll talk through five narratives that were popular, or that are popular, to answer, like, this is the blocker. Like, we can't have payments because of, I don't know, scalability, let's say, right? So these will be the five Topics that we'll analyze So about me. I'm the peanut brain at peanut protocol. You can look me up Here and also DM me here So, let's go and honor our ancestors I think I think it's really important to realize the first wave of blockchains and categorize these very briefly. So we had Bitcoin, which I already mentioned, and then we had a bunch of payments projects that were strictly about this cash element, strictly about making payments happen. So I think Litecoin fits that category very well, and Dash definitely does. Stellar, I would say, too. Then we have private payments, Monero and Zcash. The only ones with smart contracts are Nex and Ethereum, by the way. So despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. Despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. So when I was prepping for this talk, I had the honor to talk to some of these ancestors and people who are working on these very ancient projects. And I asked them, like, how are you going about trying to bootstrap your payment network? And one of the guys I talked to, he was running a campaign in 2017 trying to convince parking garages and, like, very local shops in one local city in the US to adopt their coin as one of the payment methods. As you might guess, it's quite a hopeless endeavor endeavor because you not only have to convince the garages, but also you have to convince all the drivers to adopt your thing in an ecosystem where there is the dollar already and people are used to coins and dollar notes. So what's the advantage of bootstrapping that one token, one chain thing? I think quite similarly, we have... Who's been at ECC this year? Nice. Cool. You might have seen the payments cafe by base. They were selling cappuccinos where you could just take your Coinbase wallet and just make a payment for a cappuccino. And there I wondered, well, isn't it the same case? What's my reason to switch over from that? Like opening up my wallet and so on when I'm so used to just tapping my card, right? Especially that was just USDC on base with which you could pay. So here are the candidates. One common narrative will be scalability. So we need fast and cheap for transactions I'll kind of argue against that then another one is privacy I think highly important in a world where we have full adoption and most payments happen On chain, but I will also argue that we can have a world where settlement happens on chain butts And stuff is still reasonably private. Then another argument that is very common is, well, payments are not on chain yet, or haven't captured a whole payments market in TratFi because stablecoins are relatively new. I'll also argue against that. And then finally, for the 4337 mafia, one common argument is, hey, we need better account management. We have to have account abstraction, all these nice UX improvements. I will also say, well, that's not the main blocker here. And then finally, we'll go into the interrupt thesis. So let's start. I think this is a very common thing, especially in the early days of blockchains. This was a very, very common thing to hear when people were pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. we're pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. So Visa has 24,000 TPS, and my blockchain is so much faster. It has 69,000 TPS, right? I think, again, this kind of, it's a bad comparison because you're comparing these very raw payments of just transferring value from A to B with Visa, which is this very, very complex, very bundled payment solution. And then also, perhaps more importantly for the argument here, is there should be a subset of payments where this doesn't matter right so if i do a one million dollar transaction and there are hundreds of thousands of these happening every day or millions maybe even well definitely millions then it shouldn't matter whether i'm you know using bitcoin um which is slow and relatively expensive. But by the way, what do you think, what are current Bitcoin fees today? If I want to send $1 million to another country, what's the fee on Bitcoin in dollars? Any guesses? Yeah, $1. Yeah, that's not much. You can't do that in Tratva. You can't send $1 million to another country with one buck. You can't do that. Not in that order of magnitude, right? So clearly there should be some subset of payments where it would be more efficient to already use Bitcoin, something as simple as Bitcoin, as the kind of international settlement thing. This is especially true for rare international pairs where normally you would be doing many hops between banks, so the way a TradFi international payment works is you're sending it kind of they're exchanging these IOUs and they have these very custom agreements between each other to trust each other with these IOUs. So when you're sending, let's say, money from Armenia to Chile, it might very well be the case that this payment is going to do five or six hops across the world. So first to a more local bank, and then to another one, maybe then to some US bank, and then finally to some Latin bank, and then finally to Chile. In the meantime, you don't know where the payment is and the fees you don't know how much each intermediary is going to collect. So already this should be more, even with Bitcoin, something as primitive as Bitcoin, like V1 of blockchains, it should be more efficient. But guess what? Here's my startup idea. Why don't we do a TransferWise but with Bitcoin rails? So the way TransferWise works is you have these bank accounts in different countries, and then they kind of just internally settle the payment. So they front it for you. They receive it in one country, then they front it to you in the other country. Well, here's the problem. For that to happen, you would need two banks to agree not to ban you for your Bitcoin payments. So if you can convince two banks not to ban you because you're not fitting their AML requirements or they don't know what you're doing or they're just scared of Bitcoin or they think it's like some shady thing, then you might as well just have a normal, very classical IOU-type contract with these guys to just do a normal settlement. So if you've identified this pair where there's a lot of sudden trade happening, and it's not been captured yet, let's say, I don't know, Chileans suddenly get obsessed about Ethiopian coffee, if suddenly there's a lot of trade happening, immediately there will be someone who will try to capture those flows to avoid all these inefficiencies with these hops, right? And you can do so with IOUs for these large transactions. So this very convincing narrative, like when you hear it for the first time, oh yeah, sure, let's use crypto rails just for the international part, is actually maybe not as strong for these larger B2B transactions, especially when it comes to global supply chains. Cool. Another narrative, privacy. Well, we can't penetrate the whole market unless we have privacy. Obviously, if I go somewhere and I buy my coffee, I don't want to broadcast that to literally the entire world that I just bought a pumpkin spice latte. That's extremely embarrassing, and I don't want other people to know. I think, well, again, that does not much for the just Rails thesis, because you could have some kind of company that wraps Monero or Zcash or some other solution and makes it into a nice payment thing. But also you could just obfuscate using centralized means, right? And that hasn't popped up yet. We've not truly challenged payments that way. So I don't think that's the main blocker. Okay, another very, very common one. So stablecoins. Very, very hot topic right now. Stablecoins have found PMF, product market fit, mostly as collateral for DeFi stuff, right? They haven't necessarily, or at least early on, they haven't found PMF for payments. We haven't seen that much action in terms of stablecoin payments. It's changing now. I think there's this emerging, very nascent stable coin payments market, which is extremely exciting. But that's also not the main blocker for the crypto rail thesis, because, I mean, if I'm just using it for one hop, so I'm selling my whatever, Polo Slotties here, and then sending them over to Brazil, then it's just one hop over Bitcoin. The next block, I'm already selling it. So the fluctuation of the value doesn't matter too much. And also, it's just false that you can't make payments with a highly volatile currency, right? Like hundreds of countries have, or dozens of countries have highly volatile currencies, and yet somehow people get paid and have salaries and so on. So another thesis, accounts, right? So here the idea is that we need something like account abstraction for mass adoption, better onboarding, stuff like account recovery, more granular permissions. If you think about it, it's kind of crazy that I need exactly the same level of permissions to send $1 and to send $1 million. But again, there should be some subset of payments where all of this doesn't matter because we do have these professionalised custodians we can have like for larger B2b payments we could have all of that so What's needed to unlock? these Payments for everyone to have this peer-to-peer cash that is fully on chain. So I'd like to argue that it's As simple as interoperability with everything else. So I Mentioned early on this guy who was going around garages trying to convince them, hey, adopt our coin for parking fees, and unfortunately they weren't very successful. Well, because it wasn't interoperable with standard ways of paying for parking. So here's the thesis. Interoperability is a necessary condition for interchangeability, which makes money, right? Like, money has to be spendable, which in turn is a necessary condition for any new payment network. So essentially, the idea of bootstrapping a whole payment network from scratch is kind of like that won't work right so what does this mean in practice so in practice this means that we need to slightly defragment parts of our current ecosystem so this is an example from I think a year ago blog post by Vitalik he posed the problem, hey, I have coins on Scrawl, but I want to pay on Tyco. What do I do? Super annoying. If I want USDC, 10 USDC on Optimism, you want 10 USDT on Arbitrum. Super annoying. Another one is, maybe I have some stable coins, but you want fiat. That's a problem we recently asked how we could solve that. And this is what I mean by interoperability. So making it such that it's not one chain, one token, but any chain, any token, and even fiat crypto. So we have a November challenge, which is the no-sex challenge to avoid using centralized exchanges for a whole month. If you want to hit me up, I can share the details later. But back to this idea, how can we achieve this interoperability? Well, it's really, really hard because not all blockchains talk to each other very well. And also fiat and crypto doesn't talk to each other very well. So there needs to be some layers of abstraction that let all of this get routed correctly. And I think one approach is to lock up the funds and then let them be routed where they need to go. And this is something we've been researching for the past one and a half years. But also, I'd like to very briefly mention that it might be the case that payments are currently being eaten by Visa and MasterCard. Crypto payments are being eaten by that because there's this huge emergence of cards, of crypto cards, which I'm using too, by the way. I think they're extremely convenient and a great tool. But we also need to ask ourselves, well, maybe we can skip that step, right? Maybe we can somehow be interoperable in such a way that the merchant receives this raw, simple payment without all of these extra things like the rewards, points, chargebacks, because not for all payment types they're needed, right? So maybe we need to unbundle the payment a little bit. As one of the final notes, I'd like to, this is a quote I found when I was researching for this presentation and it's from 2014. And this was from someone from the Bitcoin Foundation and essentially she said that you can send money over the internet, which is super useful for especially the unbanked, right? So maybe the, it's really interesting for me to see that this was the narrative 10 years ago, and still it's a really, really important part of what we're doing. So, to summarize, we have briefly discussed scalability, where we discovered that for some subset of payments, it shouldn't matter. But if it doesn't matter for these payments, you need these banks to anyway agree, then you might as well go directly through the banks and not use the crypto rails. We've discovered the benefits of account abstraction and easy onboarding for like a mass payment. We briefly discussed stablecoins and what role they could play in the payment space. Then we briefly discussed privacy and the needs there, and, like, is it going to happen? And then, finally, we discussed what interoperability means on a technical level, but I'd also like to briefly touch on the regulatory level, where, essentially, by having regulatory clarity, we can convince more and more of these stratify institutions to be, well, interoperable with our payment systems. So, yeah, long story short, I strongly believe that the next generation of banks will simply skip the neobank stage. So if you think about the Western world, we had traditional banks, then we had Revolut, Monzo, and so on. I think in a lot of emergent economies, we'll simply skip that stage, and the next generation of banks will be partially on-chain banks that are interoperable with TradFi. Yeah. If you want to talk payments, if you want to exchange memes, please DM me. These are my details. Yeah. Open to questions. Alright. Okay. And now we come to the Q&A session. You guys see the QR code on the screen? Any questions for the speaker? Please scan. Okay. Here we go, man. The first one coming. All right. What are your thoughts on agents using stable coins for online purchases? And agents, agent to agents, that's the dead thing, I guess, human payments. Let's go. Yes. Let's do it. I mean, I think, you know, the idea of Intents is much, much broader than just Intents for a swap or a cross-chain swap. Intents can be, you know, just orders for something, and I can just express something like, hey, I want a pizza for so and so many Bitcoin, and someone should be able to go around the world, whether that's a human or an autonomous, well, a bot or AI agent, and solve that for me, right? I think that's clearly something that will happen where all these searches will be done by bots. All right, we have a second question. Second question. Is privacy a blocker for widespread adoption? Yes, but also we don't have widespread adoption yet. So if you think about your payments that you've made, probably this week you've made several dozen payments for coffees, Ubers, maybe to your landlord, maybe you've received a salary that were not on chain. And privacy, yeah, simply, it's too small of a percentage of payments to matter in a big way. So I think it will be a huge problem and will be a blocker, but just not yet. And we have a path forward, right? Like we know how to at least have soft privacy without getting jailed. More questions coming. All right, there's a third one right there. How important is financial literacy? I think hugely important in emergent economies, right? So if you think about emergent economies, the financial products that they have access to, that normal people have access to, are extremely primitive. A lot of people are still saving their salaries in dollars rather than, I don't know, something like the S&P 500 or Ethereum. And they simply don't have access to more sophisticated financial products. All of this will need a lot of education. But for now, I think also we can make more sophisticated financial products accessible to emerging economies through crypto. And we have the fourth question. Can monopolies do anything? Well, yeah, that's a very, very good question. I think the main challenge right now is that Visa and Mastercard have a very, very lucrative reward system, which the merchants pay for, right? So if you think about a credit card payment versus a debit card payment, if you're using a credit card and you're getting some cash back or some other rewards, you're essentially getting subsidized by all the people who paid in cash or with a debit card. I think that's a cycle that's very, very hard to break. And that's why I think the first widespread on-chain payment system will emerge in emerging economies where penetration of Visa and MasterCard isn't that high, and we will have to build our own similar reward system, maybe some crypto-native distribution methods that high and we will have to build our own similar reward system, maybe some crypto native distribution methods like future airdrops and stuff like that might be a very good way to bootstrap a payments network. We have one minute left for the Q&A so maybe we can get this two or three questions. What specific domains or use cases for payments do you think are most promising in the near term? I think we have this incredible explosion of remote work and global work and global teams in crypto. Almost, well, the majority of teams is somehow globally distributed. Payments are frankly a pain in the butt to manage. I think we will see a huge emergence of on-chain payments that then use some kind of localized off-ramps. Yeah. Let's do the last question. Yeah. At what level is adoption? Oh, super low. I mean, we don't know, right? Well, we don't know, because it's very hard to estimate, but I mean, it's definitely sub 1%, and if you account for all payments, and probably sub 0.1%. All right, all right. Thank you, you guys. A big applause to the Urban, please.", - "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731403800000, - "slot_roomId": "stage-6", - "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY", - "resources_slides": null, - "speakers": [ - "konrad-urban" - ] - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -846552,7 +847223,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -846781,8 +847451,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -846795,6 +847467,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "web3-security-is-embarrasing", + "sourceId": "VNFNDM", + "title": "Web3 Security is Embarrasing", + "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "phishing", + "protection" + ], + "tags": [ + "Security", + "Sustainability", + "User Experience" + ], + "language": "en", + "speakers": [ + "andrew-macpherson" + ], + "eventId": "devcon-7", + "slot_start": 1731573000000, + "slot_end": 1731574800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM" + }, + "vector": [ + 6, 0, 0, 0, @@ -847177,7 +847885,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -847267,7 +847974,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -847511,6 +848217,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847538,6 +848245,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -847551,7 +848259,20 @@ 0, 0, 0, - 2, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -847581,7 +848302,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -847688,7 +848408,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -847696,7 +848415,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -847705,51 +848423,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "western-liberalism-to-world-liberalism", - "sourceId": "H8N9CP", - "title": "Western liberalism to world liberalism", - "description": "Western liberalism to world liberalism", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "liberalism" - ], - "tags": [ - "Ethereum for Good", - "Free Speech", - "Network State" - ], - "language": "en", - "speakers": [ - "diego-fernandez", - "bruno-macaes", - "vitalik-buterin", - "afra-zhao-wang", - "ahmed-gatnash" - ], - "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731657600000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -847916,6 +848595,39 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -847937,7 +848649,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -848096,9 +848807,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -848111,6 +848824,49 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "web3-user-research-101", + "sourceId": "7YZGVW", + "title": "Web3 User Research 101", + "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.", + "track": "Usability", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Design", + "featured": true, + "doNotRecord": false, + "keywords": [ + "101" + ], + "tags": [ + "Best Practices", + "User Experience", + "UI/UX", + "User Research", + "Design Thinking", + "101", + "Best Practices", + "Design Thinking", + "UI/UX", + "User Experience", + "User Research" + ], + "language": "en", + "speakers": [ + "mindy-harrell", + "kristina-mayman" + ], + "eventId": "devcon-7", + "slot_start": 1731398400000, + "slot_end": 1731405600000, + "slot_roomId": "classroom-c", + "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y" + }, + "vector": [ 0, 0, 0, @@ -848119,6 +848875,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -848180,7 +848937,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -848262,7 +849018,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -848277,7 +849032,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -848321,7 +849075,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -848509,7 +849262,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -848529,7 +849281,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -848608,7 +849359,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -848833,6 +849583,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -848874,6 +849626,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -848888,6 +849641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -848915,6 +849669,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -848942,6 +849697,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -848998,6 +849754,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -849046,14 +849804,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -849061,45 +849817,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "what-defi-founders-can-learn-from-web2", - "sourceId": "QB8CGR", - "title": "What DeFi Founders Can Learn From Web2", - "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.", - "track": "Real World Ethereum", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Business", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Metrics", - "Unit economics", - "Growth" - ], - "tags": [], - "language": "en", - "speakers": [ - "mike-silagadze" - ], - "eventId": "devcon-7", - "slot_start": 1731480600000, - "slot_end": 1731481200000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -849430,6 +850153,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -849447,6 +850174,80 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0 + ] + }, + { + "session": { + "id": "wen-p2p-electronic-cash-system", + "sourceId": "ZFX3ZF", + "title": "Wen p2p Electronic Cash System?", + "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).", + "track": "Real World Ethereum", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "tags": [ + "Conviction", + "Payment", + "Account Abstraction", + "stablecoin", + "Account Abstraction", + "Conviction", + "Payment" + ], + "keywords": [ + "payments", + "cash", + "stablecoins" + ], + "duration": 1549, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "7JFFfcT1yzI", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673321cc3a168eb53554b6fe.vtt", + "transcript_text": " Hello. Hello. Cool. Who knows in which year the peer-to-peer electronic cash system paper came out? Anyone else? I'm sure you know. Just three people? Four people? Okay, which year was it? 2008, right? So we're still waiting for that peer-to-peer electronic cash. I think it's fair to say that we've not taken over the peer-to-peer payments world. Bitcoin has definitely found PMF product market fit with store of value. And I don't want to argue that there are no payments on Bitcoin. But clearly, the last payments you've made to come here, maybe with your Grab or Bolt or Uber were probably not Bitcoin or on-chain payments at all. Just to show how ancient this paper is, this is 2008, right? So in 2008, GTA 4 came out. That's how long ago this was. The iPhone just came out a year earlier. People dressed like this. I think it's cool, but also very, very ancient. Bitcoin was largely, well, came out right in time as a perfect reaction to the financial crisis of 2007-2008. This is how long ago it was. a perfect reaction to the financial crisis of 2007-8. This is how long ago it was. I think we all here know what peer-to-peer means, but let's briefly talk about the cash part, because I think it's very easy to think of cash as payments. But payments are not exactly cash. I would say that cash payments are a subset of all payments. And usually when we talk about payments, we talk about something that's much, much more complicated. So last time you ordered your Grab to get here, you made probably a credit card payment. With that there was a very big bundle of services that enabled things like chargebacks, maybe you were using a credit card and definitely there are some points and rewards so I'm still waiting for the visa and MasterCard airdrop. But I would just want to talk about the simplest of payments like this very raw payment which just goes payer to payee without all of these bundled services. So this is what we usually mean by cash payment, right? Like if I give 100 baht to a taxi driver, there's no way to charge back unless I hunt him down somehow. There are also no points and there's definitely not a credit system. So for today, I'd briefly like to talk about why we haven't taken over the world yet and what's needed to take over the world with on-chain payments. So I'll give a mini intro about myself and then we'll go through a mini history just to honor our ancestors. And then I'll talk through five narratives that were popular, or that are popular, to answer, like, this is the blocker. Like, we can't have payments because of, I don't know, scalability, let's say, right? So these will be the five Topics that we'll analyze So about me. I'm the peanut brain at peanut protocol. You can look me up Here and also DM me here So, let's go and honor our ancestors I think I think it's really important to realize the first wave of blockchains and categorize these very briefly. So we had Bitcoin, which I already mentioned, and then we had a bunch of payments projects that were strictly about this cash element, strictly about making payments happen. So I think Litecoin fits that category very well, and Dash definitely does. Stellar, I would say, too. Then we have private payments, Monero and Zcash. The only ones with smart contracts are Nex and Ethereum, by the way. So despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. Despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. So when I was prepping for this talk, I had the honor to talk to some of these ancestors and people who are working on these very ancient projects. And I asked them, like, how are you going about trying to bootstrap your payment network? And one of the guys I talked to, he was running a campaign in 2017 trying to convince parking garages and, like, very local shops in one local city in the US to adopt their coin as one of the payment methods. As you might guess, it's quite a hopeless endeavor endeavor because you not only have to convince the garages, but also you have to convince all the drivers to adopt your thing in an ecosystem where there is the dollar already and people are used to coins and dollar notes. So what's the advantage of bootstrapping that one token, one chain thing? I think quite similarly, we have... Who's been at ECC this year? Nice. Cool. You might have seen the payments cafe by base. They were selling cappuccinos where you could just take your Coinbase wallet and just make a payment for a cappuccino. And there I wondered, well, isn't it the same case? What's my reason to switch over from that? Like opening up my wallet and so on when I'm so used to just tapping my card, right? Especially that was just USDC on base with which you could pay. So here are the candidates. One common narrative will be scalability. So we need fast and cheap for transactions I'll kind of argue against that then another one is privacy I think highly important in a world where we have full adoption and most payments happen On chain, but I will also argue that we can have a world where settlement happens on chain butts And stuff is still reasonably private. Then another argument that is very common is, well, payments are not on chain yet, or haven't captured a whole payments market in TratFi because stablecoins are relatively new. I'll also argue against that. And then finally, for the 4337 mafia, one common argument is, hey, we need better account management. We have to have account abstraction, all these nice UX improvements. I will also say, well, that's not the main blocker here. And then finally, we'll go into the interrupt thesis. So let's start. I think this is a very common thing, especially in the early days of blockchains. This was a very, very common thing to hear when people were pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. we're pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. So Visa has 24,000 TPS, and my blockchain is so much faster. It has 69,000 TPS, right? I think, again, this kind of, it's a bad comparison because you're comparing these very raw payments of just transferring value from A to B with Visa, which is this very, very complex, very bundled payment solution. And then also, perhaps more importantly for the argument here, is there should be a subset of payments where this doesn't matter right so if i do a one million dollar transaction and there are hundreds of thousands of these happening every day or millions maybe even well definitely millions then it shouldn't matter whether i'm you know using bitcoin um which is slow and relatively expensive. But by the way, what do you think, what are current Bitcoin fees today? If I want to send $1 million to another country, what's the fee on Bitcoin in dollars? Any guesses? Yeah, $1. Yeah, that's not much. You can't do that in Tratva. You can't send $1 million to another country with one buck. You can't do that. Not in that order of magnitude, right? So clearly there should be some subset of payments where it would be more efficient to already use Bitcoin, something as simple as Bitcoin, as the kind of international settlement thing. This is especially true for rare international pairs where normally you would be doing many hops between banks, so the way a TradFi international payment works is you're sending it kind of they're exchanging these IOUs and they have these very custom agreements between each other to trust each other with these IOUs. So when you're sending, let's say, money from Armenia to Chile, it might very well be the case that this payment is going to do five or six hops across the world. So first to a more local bank, and then to another one, maybe then to some US bank, and then finally to some Latin bank, and then finally to Chile. In the meantime, you don't know where the payment is and the fees you don't know how much each intermediary is going to collect. So already this should be more, even with Bitcoin, something as primitive as Bitcoin, like V1 of blockchains, it should be more efficient. But guess what? Here's my startup idea. Why don't we do a TransferWise but with Bitcoin rails? So the way TransferWise works is you have these bank accounts in different countries, and then they kind of just internally settle the payment. So they front it for you. They receive it in one country, then they front it to you in the other country. Well, here's the problem. For that to happen, you would need two banks to agree not to ban you for your Bitcoin payments. So if you can convince two banks not to ban you because you're not fitting their AML requirements or they don't know what you're doing or they're just scared of Bitcoin or they think it's like some shady thing, then you might as well just have a normal, very classical IOU-type contract with these guys to just do a normal settlement. So if you've identified this pair where there's a lot of sudden trade happening, and it's not been captured yet, let's say, I don't know, Chileans suddenly get obsessed about Ethiopian coffee, if suddenly there's a lot of trade happening, immediately there will be someone who will try to capture those flows to avoid all these inefficiencies with these hops, right? And you can do so with IOUs for these large transactions. So this very convincing narrative, like when you hear it for the first time, oh yeah, sure, let's use crypto rails just for the international part, is actually maybe not as strong for these larger B2B transactions, especially when it comes to global supply chains. Cool. Another narrative, privacy. Well, we can't penetrate the whole market unless we have privacy. Obviously, if I go somewhere and I buy my coffee, I don't want to broadcast that to literally the entire world that I just bought a pumpkin spice latte. That's extremely embarrassing, and I don't want other people to know. I think, well, again, that does not much for the just Rails thesis, because you could have some kind of company that wraps Monero or Zcash or some other solution and makes it into a nice payment thing. But also you could just obfuscate using centralized means, right? And that hasn't popped up yet. We've not truly challenged payments that way. So I don't think that's the main blocker. Okay, another very, very common one. So stablecoins. Very, very hot topic right now. Stablecoins have found PMF, product market fit, mostly as collateral for DeFi stuff, right? They haven't necessarily, or at least early on, they haven't found PMF for payments. We haven't seen that much action in terms of stablecoin payments. It's changing now. I think there's this emerging, very nascent stable coin payments market, which is extremely exciting. But that's also not the main blocker for the crypto rail thesis, because, I mean, if I'm just using it for one hop, so I'm selling my whatever, Polo Slotties here, and then sending them over to Brazil, then it's just one hop over Bitcoin. The next block, I'm already selling it. So the fluctuation of the value doesn't matter too much. And also, it's just false that you can't make payments with a highly volatile currency, right? Like hundreds of countries have, or dozens of countries have highly volatile currencies, and yet somehow people get paid and have salaries and so on. So another thesis, accounts, right? So here the idea is that we need something like account abstraction for mass adoption, better onboarding, stuff like account recovery, more granular permissions. If you think about it, it's kind of crazy that I need exactly the same level of permissions to send $1 and to send $1 million. But again, there should be some subset of payments where all of this doesn't matter because we do have these professionalised custodians we can have like for larger B2b payments we could have all of that so What's needed to unlock? these Payments for everyone to have this peer-to-peer cash that is fully on chain. So I'd like to argue that it's As simple as interoperability with everything else. So I Mentioned early on this guy who was going around garages trying to convince them, hey, adopt our coin for parking fees, and unfortunately they weren't very successful. Well, because it wasn't interoperable with standard ways of paying for parking. So here's the thesis. Interoperability is a necessary condition for interchangeability, which makes money, right? Like, money has to be spendable, which in turn is a necessary condition for any new payment network. So essentially, the idea of bootstrapping a whole payment network from scratch is kind of like that won't work right so what does this mean in practice so in practice this means that we need to slightly defragment parts of our current ecosystem so this is an example from I think a year ago blog post by Vitalik he posed the problem, hey, I have coins on Scrawl, but I want to pay on Tyco. What do I do? Super annoying. If I want USDC, 10 USDC on Optimism, you want 10 USDT on Arbitrum. Super annoying. Another one is, maybe I have some stable coins, but you want fiat. That's a problem we recently asked how we could solve that. And this is what I mean by interoperability. So making it such that it's not one chain, one token, but any chain, any token, and even fiat crypto. So we have a November challenge, which is the no-sex challenge to avoid using centralized exchanges for a whole month. If you want to hit me up, I can share the details later. But back to this idea, how can we achieve this interoperability? Well, it's really, really hard because not all blockchains talk to each other very well. And also fiat and crypto doesn't talk to each other very well. So there needs to be some layers of abstraction that let all of this get routed correctly. And I think one approach is to lock up the funds and then let them be routed where they need to go. And this is something we've been researching for the past one and a half years. But also, I'd like to very briefly mention that it might be the case that payments are currently being eaten by Visa and MasterCard. Crypto payments are being eaten by that because there's this huge emergence of cards, of crypto cards, which I'm using too, by the way. I think they're extremely convenient and a great tool. But we also need to ask ourselves, well, maybe we can skip that step, right? Maybe we can somehow be interoperable in such a way that the merchant receives this raw, simple payment without all of these extra things like the rewards, points, chargebacks, because not for all payment types they're needed, right? So maybe we need to unbundle the payment a little bit. As one of the final notes, I'd like to, this is a quote I found when I was researching for this presentation and it's from 2014. And this was from someone from the Bitcoin Foundation and essentially she said that you can send money over the internet, which is super useful for especially the unbanked, right? So maybe the, it's really interesting for me to see that this was the narrative 10 years ago, and still it's a really, really important part of what we're doing. So, to summarize, we have briefly discussed scalability, where we discovered that for some subset of payments, it shouldn't matter. But if it doesn't matter for these payments, you need these banks to anyway agree, then you might as well go directly through the banks and not use the crypto rails. We've discovered the benefits of account abstraction and easy onboarding for like a mass payment. We briefly discussed stablecoins and what role they could play in the payment space. Then we briefly discussed privacy and the needs there, and, like, is it going to happen? And then, finally, we discussed what interoperability means on a technical level, but I'd also like to briefly touch on the regulatory level, where, essentially, by having regulatory clarity, we can convince more and more of these stratify institutions to be, well, interoperable with our payment systems. So, yeah, long story short, I strongly believe that the next generation of banks will simply skip the neobank stage. So if you think about the Western world, we had traditional banks, then we had Revolut, Monzo, and so on. I think in a lot of emergent economies, we'll simply skip that stage, and the next generation of banks will be partially on-chain banks that are interoperable with TradFi. Yeah. If you want to talk payments, if you want to exchange memes, please DM me. These are my details. Yeah. Open to questions. Alright. Okay. And now we come to the Q&A session. You guys see the QR code on the screen? Any questions for the speaker? Please scan. Okay. Here we go, man. The first one coming. All right. What are your thoughts on agents using stable coins for online purchases? And agents, agent to agents, that's the dead thing, I guess, human payments. Let's go. Yes. Let's do it. I mean, I think, you know, the idea of Intents is much, much broader than just Intents for a swap or a cross-chain swap. Intents can be, you know, just orders for something, and I can just express something like, hey, I want a pizza for so and so many Bitcoin, and someone should be able to go around the world, whether that's a human or an autonomous, well, a bot or AI agent, and solve that for me, right? I think that's clearly something that will happen where all these searches will be done by bots. All right, we have a second question. Second question. Is privacy a blocker for widespread adoption? Yes, but also we don't have widespread adoption yet. So if you think about your payments that you've made, probably this week you've made several dozen payments for coffees, Ubers, maybe to your landlord, maybe you've received a salary that were not on chain. And privacy, yeah, simply, it's too small of a percentage of payments to matter in a big way. So I think it will be a huge problem and will be a blocker, but just not yet. And we have a path forward, right? Like we know how to at least have soft privacy without getting jailed. More questions coming. All right, there's a third one right there. How important is financial literacy? I think hugely important in emergent economies, right? So if you think about emergent economies, the financial products that they have access to, that normal people have access to, are extremely primitive. A lot of people are still saving their salaries in dollars rather than, I don't know, something like the S&P 500 or Ethereum. And they simply don't have access to more sophisticated financial products. All of this will need a lot of education. But for now, I think also we can make more sophisticated financial products accessible to emerging economies through crypto. And we have the fourth question. Can monopolies do anything? Well, yeah, that's a very, very good question. I think the main challenge right now is that Visa and Mastercard have a very, very lucrative reward system, which the merchants pay for, right? So if you think about a credit card payment versus a debit card payment, if you're using a credit card and you're getting some cash back or some other rewards, you're essentially getting subsidized by all the people who paid in cash or with a debit card. I think that's a cycle that's very, very hard to break. And that's why I think the first widespread on-chain payment system will emerge in emerging economies where penetration of Visa and MasterCard isn't that high, and we will have to build our own similar reward system, maybe some crypto-native distribution methods that high and we will have to build our own similar reward system, maybe some crypto native distribution methods like future airdrops and stuff like that might be a very good way to bootstrap a payments network. We have one minute left for the Q&A so maybe we can get this two or three questions. What specific domains or use cases for payments do you think are most promising in the near term? I think we have this incredible explosion of remote work and global work and global teams in crypto. Almost, well, the majority of teams is somehow globally distributed. Payments are frankly a pain in the butt to manage. I think we will see a huge emergence of on-chain payments that then use some kind of localized off-ramps. Yeah. Let's do the last question. Yeah. At what level is adoption? Oh, super low. I mean, we don't know, right? Well, we don't know, because it's very hard to estimate, but I mean, it's definitely sub 1%, and if you account for all payments, and probably sub 0.1%. All right, all right. Thank you, you guys. A big applause to the Urban, please.", + "eventId": "devcon-7", + "slot_start": 1731402000000, + "slot_end": 1731403800000, + "slot_roomId": "stage-6", + "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY", + "resources_slides": null, + "speakers": [ + "konrad-urban" + ] + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -849603,6 +850404,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -849807,7 +850609,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -850231,6 +851032,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850320,6 +851122,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850396,12 +851199,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -850411,40 +851212,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks", - "sourceId": "NL3A7T", - "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs", - "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.", - "track": "Security", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ZKPs", - "Security" - ], - "tags": [ - "Security" - ], - "language": "en", - "speakers": [ - "stefanos-chaliasos" - ], - "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731645000000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc" - }, - "vector": [ - 6, 0, 0, 0, @@ -850639,6 +851406,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850668,6 +851436,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850774,6 +851543,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850781,6 +851551,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -850789,12 +851560,51 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "western-liberalism-to-world-liberalism", + "sourceId": "H8N9CP", + "title": "Western liberalism to world liberalism", + "description": "Western liberalism to world liberalism", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "liberalism" + ], + "tags": [ + "Ethereum for Good", + "Free Speech", + "Network State" + ], + "language": "en", + "speakers": [ + "diego-fernandez", + "bruno-macaes", + "vitalik-buterin", + "afra-zhao-wang", + "ahmed-gatnash" + ], + "eventId": "devcon-7", + "slot_start": 1731654000000, + "slot_end": 1731657600000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -850983,6 +851793,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -851159,7 +851970,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -851183,7 +851993,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -851228,6 +852037,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -851309,6 +852119,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -851323,6 +852134,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -851365,6 +852177,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -851555,6 +852368,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -851574,6 +852388,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -851652,6 +852467,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -851745,11 +852562,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -851762,48 +852577,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "what-is-the-status-of-epbs-and-its-future-iterations", - "sourceId": "3MUYVQ", - "title": "What is the status of ePBS and its future iterations", - "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "PBS", - "consensus", - "fork-choice" - ], - "tags": [ - "PBS", - "fork", - "choice", - "PBS" - ], - "language": "en", - "speakers": [ - "potuz" - ], - "eventId": "devcon-7", - "slot_start": 1731472200000, - "slot_end": 1731474000000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -852128,12 +852905,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -852141,6 +852920,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "what-defi-founders-can-learn-from-web2", + "sourceId": "QB8CGR", + "title": "What DeFi Founders Can Learn From Web2", + "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.", + "track": "Real World Ethereum", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Business", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Metrics", + "Unit economics", + "Growth" + ], + "tags": [], + "language": "en", + "speakers": [ + "mike-silagadze" + ], + "eventId": "devcon-7", + "slot_start": 1731480600000, + "slot_end": 1731481200000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs" + }, + "vector": [ + 0, + 0, + 0, + 0, + 0, + 0, + 6, 0, 0, 0, @@ -852515,7 +853333,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -852577,7 +853394,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -852767,7 +853583,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -852855,6 +853670,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -853082,7 +853898,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -853100,11 +853915,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -853117,55 +853930,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "whats-going-into-the-pectra-upgrade", - "sourceId": "9WTJRX", - "title": "What’s Going Into the Pectra Upgrade?", - "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "tags": [ - "fork", - "hard" - ], - "keywords": [ - "Pectra", - "Governance", - "Hard forks" - ], - "duration": 1515, - "language": "en", - "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f", - "sources_youtubeId": "ufIDBCgdGwY", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt", - "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...", - "eventId": "devcon-7", - "slot_start": 1731391200000, - "slot_end": 1731393000000, - "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc", - "resources_slides": null, - "speakers": [ - "christine-kim" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -853491,10 +854259,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -853504,6 +854274,40 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks", + "sourceId": "NL3A7T", + "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs", + "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.", + "track": "Security", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZKPs", + "Security" + ], + "tags": [ + "Security" + ], + "language": "en", + "speakers": [ + "stefanos-chaliasos" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731645000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc" + }, + "vector": [ + 6, 0, 0, 0, @@ -853878,7 +854682,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -854129,7 +854932,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -854224,6 +855026,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -854247,6 +855050,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -854445,7 +855249,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -854464,14 +855267,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -854479,41 +855280,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "white-rabbit-world-premiere", - "sourceId": "7CFGTS", - "title": "White Rabbit World Premiere", - "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes", - "track": "Entertainment", - "type": "Music", - "expertise": "Beginner", - "audience": "Design", - "featured": false, - "doNotRecord": false, - "keywords": [ - "animation", - "film", - "nft" - ], - "tags": [ - "Account", - "Abstraction" - ], - "language": "en", - "speakers": [ - "pplpleasr" - ], - "eventId": "devcon-7", - "slot_start": 1731497400000, - "slot_end": 1731500100000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc" - }, - "vector": [ 0, 0, 0, @@ -854523,7 +855289,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -854847,9 +855612,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -854862,6 +855629,50 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "what-is-the-status-of-epbs-and-its-future-iterations", + "sourceId": "3MUYVQ", + "title": "What is the status of ePBS and its future iterations", + "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "PBS", + "consensus", + "fork-choice" + ], + "tags": [ + "PBS", + "fork", + "choice", + "PBS" + ], + "language": "en", + "speakers": [ + "potuz" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, 0, 0, 0, @@ -855232,7 +856043,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -855576,6 +856386,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -855634,6 +856448,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -855799,11 +856617,6 @@ 0, 0, 0, - 2, - 2, - 0, - 0, - 0, 0, 0, 0, @@ -855817,11 +856630,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -855832,83 +856640,6 @@ 0, 2, 0, - 0 - ] - }, - { - "session": { - "id": "who-needs-a-wallet-anyway", - "sourceId": "ZZKKRZ", - "title": "Who needs a wallet anyway?", - "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.", - "track": "Usability", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "Permissionless", - "Developer Infrastructure", - "Decentralization", - "Environment", - "User Experience", - "trusted", - "wallet", - "execution", - "Developer Infrastructure", - "Permissionless", - "User Experience" - ], - "keywords": [ - "Trusted", - "Execution", - "Environments" - ], - "duration": 555, - "language": "en", - "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83", - "sources_youtubeId": "iNLHWc5toYo", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt", - "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.", - "eventId": "devcon-7", - "slot_start": 1731393600000, - "slot_end": 1731394200000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg", - "resources_slides": null, - "speakers": [ - "itai-turbahn" - ] - }, - "vector": [ - 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, @@ -856222,6 +856953,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -856239,9 +856971,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -856254,10 +856988,55 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "whats-going-into-the-pectra-upgrade", + "sourceId": "9WTJRX", + "title": "What’s Going Into the Pectra Upgrade?", + "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "tags": [ + "fork", + "hard" + ], + "keywords": [ + "Pectra", + "Governance", + "Hard forks" + ], + "duration": 1515, + "language": "en", + "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f", + "sources_youtubeId": "ufIDBCgdGwY", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt", + "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...", + "eventId": "devcon-7", + "slot_start": 1731391200000, + "slot_end": 1731393000000, + "slot_roomId": "stage-1", + "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc", + "resources_slides": null, + "speakers": [ + "christine-kim" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -856604,7 +857383,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -856640,7 +857418,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -856678,7 +857455,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -856726,7 +857502,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -856796,7 +857571,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -856816,12 +857590,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -856981,6 +857753,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -856990,7 +857763,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -857052,7 +857824,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -857188,9 +857959,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -857203,45 +857972,8 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "who-wins-ethereum-block-building-auctions-and-why", - "sourceId": "VKQ8NC", - "title": "Who Wins Ethereum Block Building Auctions and Why?", - "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.", - "track": "Cryptoeconomics", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "MEV", - "PBS", - "Block Auction" - ], - "tags": [ - "blocks", - "auction" - ], - "language": "en", - "speakers": [ - "danning-sui", - "burak-oz" - ], - "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731560400000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -857272,6 +858004,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -857587,6 +858320,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -857605,12 +858339,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -857618,6 +858354,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "white-rabbit-world-premiere", + "sourceId": "7CFGTS", + "title": "White Rabbit World Premiere", + "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes", + "track": "Entertainment", + "type": "Music", + "expertise": "Beginner", + "audience": "Design", + "featured": false, + "doNotRecord": false, + "keywords": [ + "animation", + "film", + "nft" + ], + "tags": [ + "Account", + "Abstraction" + ], + "language": "en", + "speakers": [ + "pplpleasr" + ], + "eventId": "devcon-7", + "slot_start": 1731497400000, + "slot_end": 1731500100000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc" + }, + "vector": [ 0, 0, 0, @@ -857627,6 +858398,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -857959,8 +858731,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -858125,7 +858895,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -858306,7 +859075,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -858343,6 +859111,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -858540,12 +859309,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -858557,44 +859324,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "why-defi-matters-on-ethereum", - "sourceId": "E7GFJC", - "title": "Why DeFi matters on Ethereum", - "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.", - "track": "Real World Ethereum", - "type": "Panel", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [ - "tascha", - "loi-luu", - "kain-warwick", - "namik-muduroglu" - ], - "eventId": "devcon-7", - "slot_start": 1731578400000, - "slot_end": 1731582000000, - "slot_roomId": "main-stage", - "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU" - }, - "vector": [ 0, 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -858814,11 +859549,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -858948,6 +859678,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -858964,6 +859696,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -858976,7 +859709,61 @@ 0, 0, 0, + 2, 0, + 0 + ] + }, + { + "session": { + "id": "who-needs-a-wallet-anyway", + "sourceId": "ZZKKRZ", + "title": "Who needs a wallet anyway?", + "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.", + "track": "Usability", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "Permissionless", + "Developer Infrastructure", + "Decentralization", + "Environment", + "User Experience", + "trusted", + "wallet", + "execution", + "Developer Infrastructure", + "Permissionless", + "User Experience" + ], + "keywords": [ + "Trusted", + "Execution", + "Environments" + ], + "duration": 555, + "language": "en", + "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83", + "sources_youtubeId": "iNLHWc5toYo", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt", + "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.", + "eventId": "devcon-7", + "slot_start": 1731393600000, + "slot_end": 1731394200000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg", + "resources_slides": null, + "speakers": [ + "itai-turbahn" + ] + }, + "vector": [ 0, 0, 0, @@ -858985,6 +859772,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -859310,11 +860098,6 @@ 0, 0, 0, - 6, - 6, - 6, - 0, - 0, 0, 0, 0, @@ -859704,6 +860487,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -859739,6 +860523,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -859776,6 +860561,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -859823,6 +860609,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -859890,7 +860677,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -859901,53 +860687,6 @@ 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "why-erc-7683-is-broken-and-how-to-fix-it", - "sourceId": "YT3SSN", - "title": "Why ERC 7683 is broken and how to fix it", - "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "chain-abstraction", - "intents" - ], - "tags": [ - "Appchains", - "Cross-L2", - "Token bridging", - "Accessibility", - "erc-7683", - "intent", - "Accessibility", - "Appchains", - "Cross-L2", - "Token bridging" - ], - "language": "en", - "speakers": [ - "vaibhav-chellani" - ], - "eventId": "devcon-7", - "slot_start": 1731479400000, - "slot_end": 1731481200000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg" - }, - "vector": [ 0, 0, 0, @@ -859955,16 +860694,17 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -860133,6 +860873,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -860194,6 +860935,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -860329,7 +861071,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -860342,8 +861086,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "who-wins-ethereum-block-building-auctions-and-why", + "sourceId": "VKQ8NC", + "title": "Who Wins Ethereum Block Building Auctions and Why?", + "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.", + "track": "Cryptoeconomics", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "MEV", + "PBS", + "Block Auction" + ], + "tags": [ + "blocks", + "auction" + ], + "language": "en", + "speakers": [ + "danning-sui", + "burak-oz" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731560400000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -860673,7 +861454,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -860747,7 +861527,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -860860,7 +861639,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -860889,10 +861667,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -861016,7 +861792,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -861071,6 +861846,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -861249,11 +862026,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -861266,45 +862041,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "why-i-hate-on-chain-token-governance-and-you-should-too", - "sourceId": "8GCGZW", - "title": "Why I Hate On Chain Token Governance & You Should Too 😺", - "description": "Ethereum heavily utilizes it's strong social layer for protocol governance decisions. In recent years, we have seen projects try on chain token holder governance to make upgrades. This is a dangerous path and has proven itself to be susceptible to oligarchies and collusion. There is hope in the form of on chain token signaling with non-binding resolutions that are then executed by a trusted committee. Don't worry, I won't only be bitching about on chain governance with no solutions.", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "token voting", - "on chain governance" - ], - "tags": [ - "Core Protocol", - "Protocol Design", - "Governance", - "onchain", - "Core Protocol", - "Governance", - "Protocol Design" - ], - "language": "en", - "speakers": [ - "hudson-jameson" - ], - "eventId": "devcon-7", - "slot_start": 1731491400000, - "slot_end": 1731492000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1mTXnRa95nn1RwpyKujvweKeIEv-zBWW4Spl__Bd7rv0" - }, - "vector": [ 0, 0, 0, @@ -861316,7 +862052,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -861458,6 +862193,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -861591,7 +862327,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -861692,10 +862427,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -861707,12 +862444,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "why-defi-matters-on-ethereum", + "sourceId": "E7GFJC", + "title": "Why DeFi matters on Ethereum", + "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.", + "track": "Real World Ethereum", + "type": "Panel", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [ + "tascha", + "loi-luu", + "kain-warwick", + "namik-muduroglu" + ], + "eventId": "devcon-7", + "slot_start": 1731578400000, + "slot_end": 1731582000000, + "slot_roomId": "main-stage", + "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU" + }, + "vector": [ 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -861933,6 +862702,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -862063,7 +862833,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -862090,7 +862859,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -862140,7 +862908,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -862434,6 +863201,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -862467,7 +863237,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -862608,74 +863377,6 @@ 0, 0, 0, - 2, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "session": { - "id": "why-many-deployed-snarks-are-extremely-risky", - "sourceId": "BVSHEA", - "title": "Why many deployed SNARKs are extremely risky", - "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Concrete", - "security" - ], - "tags": [ - "Cryptography", - "Security", - "SNARK" - ], - "language": "en", - "speakers": [ - "pratyush-ranjan-tiwari" - ], - "eventId": "devcon-7", - "slot_start": 1731645000000, - "slot_end": 1731646800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM" - }, - "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -863080,8 +863781,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -863094,6 +863797,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "why-erc-7683-is-broken-and-how-to-fix-it", + "sourceId": "YT3SSN", + "title": "Why ERC 7683 is broken and how to fix it", + "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "chain-abstraction", + "intents" + ], + "tags": [ + "Appchains", + "Cross-L2", + "Token bridging", + "Accessibility", + "erc-7683", + "intent", + "Accessibility", + "Appchains", + "Cross-L2", + "Token bridging" + ], + "language": "en", + "speakers": [ + "vaibhav-chellani" + ], + "eventId": "devcon-7", + "slot_start": 1731479400000, + "slot_end": 1731481200000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg" + }, + "vector": [ 0, 0, 0, @@ -863101,6 +863846,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -863384,7 +864130,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -863397,7 +864142,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -863410,7 +864154,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -863679,7 +864422,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -863826,6 +864568,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -863899,6 +864642,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -863959,12 +864703,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -863976,59 +864718,11 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "why-vpns-are-scams-and-what-to-do-about-it", - "sourceId": "TRMC3L", - "title": "Why VPNs are scams and what to do about it", - "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.", - "track": "Cypherpunk & Privacy", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "tags": [ - "censorship", - "resistance", - "Decentralization", - "Privacy", - "Use Cases" - ], - "keywords": [ - "VPNs", - "mixnets", - "censorship-resistance" - ], - "duration": 538, - "language": "en", - "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6", - "sources_youtubeId": "4Ir-fptXPr8", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt", - "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.", - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731390000000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4", - "resources_slides": null, - "speakers": [ - "harry-halpin" - ] - }, - "vector": [ 0, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -864061,6 +864755,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864089,8 +864784,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -864214,6 +864911,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864432,6 +865130,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -864445,9 +865144,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -864460,6 +865161,45 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "why-i-hate-on-chain-token-governance-and-you-should-too", + "sourceId": "8GCGZW", + "title": "Why I Hate On Chain Token Governance & You Should Too 😺", + "description": "Ethereum heavily utilizes it's strong social layer for protocol governance decisions. In recent years, we have seen projects try on chain token holder governance to make upgrades. This is a dangerous path and has proven itself to be susceptible to oligarchies and collusion. There is hope in the form of on chain token signaling with non-binding resolutions that are then executed by a trusted committee. Don't worry, I won't only be bitching about on chain governance with no solutions.", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "token voting", + "on chain governance" + ], + "tags": [ + "Core Protocol", + "Protocol Design", + "Governance", + "onchain", + "Core Protocol", + "Governance", + "Protocol Design" + ], + "language": "en", + "speakers": [ + "hudson-jameson" + ], + "eventId": "devcon-7", + "slot_start": 1731491400000, + "slot_end": 1731492000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1mTXnRa95nn1RwpyKujvweKeIEv-zBWW4Spl__Bd7rv0" + }, + "vector": [ 0, 0, 0, @@ -864471,6 +865211,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -864657,7 +865398,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -864747,6 +865487,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -864841,7 +865582,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -864864,7 +865604,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -864879,7 +865618,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -865224,6 +865962,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -865250,6 +865989,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -865299,6 +866039,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -865311,8 +866052,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -865324,11 +866063,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -865341,44 +866078,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wizard-build-your-own-p-iop-protocol-in-15-min", - "sourceId": "W78CYD", - "title": "Wizard: build your own P-IOP protocol in 15 min!", - "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Polynomial-IOP" - ], - "tags": [ - "Protocol Design", - "Frameworks", - "SNARK", - "polynomial-iop", - "Frameworks", - "Protocol Design", - "SNARK" - ], - "language": "en", - "speakers": [ - "alexandre-belling" - ], - "eventId": "devcon-7", - "slot_start": 1731486600000, - "slot_end": 1731488400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo" - }, - "vector": [ 0, 0, 0, @@ -865389,8 +866088,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -865669,6 +866366,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -865809,8 +866507,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -865822,6 +866522,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "why-many-deployed-snarks-are-extremely-risky", + "sourceId": "BVSHEA", + "title": "Why many deployed SNARKs are extremely risky", + "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Concrete", + "security" + ], + "tags": [ + "Cryptography", + "Security", + "SNARK" + ], + "language": "en", + "speakers": [ + "pratyush-ranjan-tiwari" + ], + "eventId": "devcon-7", + "slot_start": 1731645000000, + "slot_end": 1731646800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM" + }, + "vector": [ 0, 0, 0, @@ -865832,6 +866567,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -866106,7 +866842,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -866164,7 +866899,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -866223,7 +866957,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -866400,7 +867133,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -866555,6 +867287,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -866567,6 +867300,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -866579,6 +867313,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -866669,7 +867404,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -866680,12 +867414,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -866697,32 +867429,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wmb-81321", - "sourceId": "S8MPDK", - "title": "WMB 81321", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731661200000, - "slot_end": 1731664800000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ" - }, - "vector": [ 0, 0, 0, @@ -866732,7 +867438,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -866877,6 +867582,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -867156,10 +867862,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -867171,11 +867879,59 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "why-vpns-are-scams-and-what-to-do-about-it", + "sourceId": "TRMC3L", + "title": "Why VPNs are scams and what to do about it", + "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.", + "track": "Cypherpunk & Privacy", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "tags": [ + "censorship", + "resistance", + "Decentralization", + "Privacy", + "Use Cases" + ], + "keywords": [ + "VPNs", + "mixnets", + "censorship-resistance" + ], + "duration": 538, + "language": "en", + "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6", + "sources_youtubeId": "4Ir-fptXPr8", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt", + "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.", + "eventId": "devcon-7", + "slot_start": 1731389400000, + "slot_end": 1731390000000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4", + "resources_slides": null, + "speakers": [ + "harry-halpin" + ] + }, + "vector": [ 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -867808,6 +868564,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -867991,6 +868748,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -868013,6 +868771,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -868025,7 +868784,6 @@ 0, 0, 0, - 2, 0, 0, 2, @@ -868041,42 +868799,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "working-together-with-unity-blazor-nethereum-and-mud", - "sourceId": "SDUYDQ", - "title": "Working together with Unity, Blazor, Nethereum and MUD", - "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Nethereum", - "MUD", - "Unity" - ], - "tags": [ - "Architecture", - "Frameworks", - "Gaming" - ], - "language": "en", - "speakers": [ - "juan-blanco" - ], - "eventId": "devcon-7", - "slot_start": 1731568500000, - "slot_end": 1731570000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q" - }, - "vector": [ 0, 0, 0, @@ -868089,7 +868811,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -868497,6 +869218,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -868508,9 +869231,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -868523,6 +869248,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wizard-build-your-own-p-iop-protocol-in-15-min", + "sourceId": "W78CYD", + "title": "Wizard: build your own P-IOP protocol in 15 min!", + "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Polynomial-IOP" + ], + "tags": [ + "Protocol Design", + "Frameworks", + "SNARK", + "polynomial-iop", + "Frameworks", + "Protocol Design", + "SNARK" + ], + "language": "en", + "speakers": [ + "alexandre-belling" + ], + "eventId": "devcon-7", + "slot_start": 1731486600000, + "slot_end": 1731488400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo" + }, + "vector": [ 0, 0, 0, @@ -868533,6 +869296,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -868805,7 +869569,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -868878,7 +869641,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -868921,13 +869683,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -869257,6 +870017,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -869314,6 +870075,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -869372,17 +870134,16 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -869395,48 +870156,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wtf-are-based-rollups-and-preconfs", - "sourceId": "UG79AE", - "title": "Wtf are based rollups and preconfs?", - "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Based Rollup", - "Preconfirmations", - "Sequencing" - ], - "tags": [ - "Validator Experience", - "Layer 2s", - "Rollups", - "sequencer", - "preconfs", - "pre-confirmations", - "Layer 2s", - "Rollups", - "Validator Experience" - ], - "language": "en", - "speakers": [ - "jason-vranek" - ], - "eventId": "devcon-7", - "slot_start": 1731642000000, - "slot_end": 1731642600000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y" - }, - "vector": [ 0, 0, 0, @@ -869444,7 +870163,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -869593,6 +870311,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -869861,6 +870580,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -869871,10 +870591,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -869886,6 +870608,32 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wmb-81321", + "sourceId": "S8MPDK", + "title": "WMB 81321", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731661200000, + "slot_end": 1731664800000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ" + }, + "vector": [ 0, 0, 0, @@ -869895,6 +870643,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -870166,7 +870915,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -870214,11 +870962,8 @@ 0, 0, 0, - 2, 0, 0, - 2, - 2, 0, 0, 0, @@ -870242,7 +870987,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -870289,8 +871033,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -870740,11 +871482,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -870755,44 +871495,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "wtf-is-the-pessimistic-proof", - "sourceId": "DAZLVG", - "title": "WTF is the pessimistic proof", - "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.", - "track": "Layer 2", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "aggLayer", - "shared liquidity" - ], - "tags": [ - "ZKP", - "liquidity", - "shared", - "agglayer", - "ZKP" - ], - "language": "en", - "speakers": [ - "ignasi-ramos", - "jesus" - ], - "eventId": "devcon-7", - "slot_start": 1731654000000, - "slot_end": 1731654600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q" - }, - "vector": [ 0, 0, 0, @@ -870800,7 +871502,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -871239,8 +871940,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -871253,6 +871956,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "working-together-with-unity-blazor-nethereum-and-mud", + "sourceId": "SDUYDQ", + "title": "Working together with Unity, Blazor, Nethereum and MUD", + "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Nethereum", + "MUD", + "Unity" + ], + "tags": [ + "Architecture", + "Frameworks", + "Gaming" + ], + "language": "en", + "speakers": [ + "juan-blanco" + ], + "eventId": "devcon-7", + "slot_start": 1731568500000, + "slot_end": 1731570000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q" + }, + "vector": [ 0, 0, 0, @@ -871265,6 +872004,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -871297,7 +872037,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -871460,7 +872199,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -871607,7 +872345,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -871616,7 +872353,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -871988,6 +872724,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -872060,6 +872797,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -872084,8 +872822,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -872094,11 +872830,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -872106,46 +872840,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "yeomenai-elevate-your-game", - "sourceId": "WLKTYW", - "title": "Yeomen.ai - Elevate your game!", - "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Talk", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Analytics", - "Modding" - ], - "tags": [ - "Autonomous World", - "Developer Infrastructure" - ], - "language": "en", - "speakers": [ - "rohan-abraham", - "roshan-abraham" - ], - "eventId": "devcon-7", - "slot_start": 1731582300000, - "slot_end": 1731583800000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU" - }, - "vector": [ + 2, 0, 0, 0, @@ -872158,7 +872859,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -872597,9 +873297,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -872612,6 +873314,48 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wtf-are-based-rollups-and-preconfs", + "sourceId": "UG79AE", + "title": "Wtf are based rollups and preconfs?", + "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Based Rollup", + "Preconfirmations", + "Sequencing" + ], + "tags": [ + "Validator Experience", + "Layer 2s", + "Rollups", + "sequencer", + "preconfs", + "pre-confirmations", + "Layer 2s", + "Rollups", + "Validator Experience" + ], + "language": "en", + "speakers": [ + "jason-vranek" + ], + "eventId": "devcon-7", + "slot_start": 1731642000000, + "slot_end": 1731642600000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y" + }, + "vector": [ 0, 0, 0, @@ -872619,6 +873363,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -872876,8 +873621,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -872939,7 +873682,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -872995,7 +873737,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -873348,6 +874089,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -873395,8 +874137,11 @@ 0, 0, 0, + 2, 0, 0, + 2, + 2, 0, 0, 0, @@ -873420,6 +874165,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -873449,11 +874195,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -873464,55 +874208,12 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "yeomenai-mud-day-demo", - "sourceId": "7DGLCG", - "title": "Yeomen.ai - MUD Day Demo", - "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.", - "track": "[CLS] MUD Community-Led Session, by 0xPARC", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Product", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Tooling", - "Gaming", - "Autonomous World", - "analytics", - "Autonomous World", - "Gaming", - "Tooling" - ], - "language": "en", - "speakers": [ - "rohan-abraham" - ], - "eventId": "devcon-7", - "slot_start": 1731558600000, - "slot_end": 1731558900000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y" - }, - "vector": [ 0, 0, 0, 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 6, + 2, + 2, 0, 0, 0, @@ -873962,9 +874663,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -873975,6 +874678,44 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "wtf-is-the-pessimistic-proof", + "sourceId": "DAZLVG", + "title": "WTF is the pessimistic proof", + "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.", + "track": "Layer 2", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "aggLayer", + "shared liquidity" + ], + "tags": [ + "ZKP", + "liquidity", + "shared", + "agglayer", + "ZKP" + ], + "language": "en", + "speakers": [ + "ignasi-ramos", + "jesus" + ], + "eventId": "devcon-7", + "slot_start": 1731654000000, + "slot_end": 1731654600000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q" + }, + "vector": [ 0, 0, 0, @@ -873982,6 +874723,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -874230,7 +874972,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -874260,7 +875001,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -874312,7 +875052,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -874349,8 +875088,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -874485,6 +875222,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -874649,6 +875387,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -874795,6 +875534,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -874809,7 +875549,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -874818,40 +875557,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy", - "sourceId": "LUKWAM", - "title": "You know what’s going to get us from web2 to web3? Therapy", - "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g", - "track": "Coordination", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "thriving", - "mental health", - "future" - ], - "tags": [ - "future" - ], - "language": "en", - "speakers": [ - "simona-pop" - ], - "eventId": "devcon-7", - "slot_start": 1731487800000, - "slot_end": 1731488400000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA" - }, - "vector": [ 0, 0, 0, @@ -874863,7 +875568,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -875062,7 +875766,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -875308,6 +876011,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -875316,9 +876021,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -875331,6 +876038,41 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "yeomenai-elevate-your-game", + "sourceId": "WLKTYW", + "title": "Yeomen.ai - Elevate your game!", + "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Talk", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Analytics", + "Modding" + ], + "tags": [ + "Autonomous World", + "Developer Infrastructure" + ], + "language": "en", + "speakers": [ + "rohan-abraham", + "roshan-abraham" + ], + "eventId": "devcon-7", + "slot_start": 1731582300000, + "slot_end": 1731583800000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU" + }, + "vector": [ 0, 0, 0, @@ -875343,6 +876085,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -876064,6 +876807,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -876125,6 +876870,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -876153,7 +876899,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -876162,7 +876907,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -876170,32 +876914,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "your-intuition-antoine-flute-and-didgeridoo", - "sourceId": "B8SMVZ", - "title": "Your intuition Antoine flute and didgeridoo", - "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", - "track": "Entertainment", - "type": "Music", - "expertise": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731389400000, - "slot_end": 1731391200000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY" - }, - "vector": [ 0, 0, 0, @@ -876205,10 +876923,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 2, 0, 0, 0, @@ -876662,9 +877380,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -876675,6 +877395,42 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "yeomenai-mud-day-demo", + "sourceId": "7DGLCG", + "title": "Yeomen.ai - MUD Day Demo", + "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.", + "track": "[CLS] MUD Community-Led Session, by 0xPARC", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Product", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Tooling", + "Gaming", + "Autonomous World", + "analytics", + "Autonomous World", + "Gaming", + "Tooling" + ], + "language": "en", + "speakers": [ + "rohan-abraham" + ], + "eventId": "devcon-7", + "slot_start": 1731558600000, + "slot_end": 1731558900000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y" + }, + "vector": [ 0, 0, 0, @@ -876687,6 +877443,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -877408,6 +878165,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -877437,6 +878195,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -877488,6 +878247,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -877498,10 +878258,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -877514,54 +878272,9 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zero-to-dapp", - "sourceId": "LUW7G9", - "title": "Zero To Dapp", - "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)", - "track": "Developer Experience", - "type": "Workshop", - "expertise": "Beginner", - "audience": "Developer", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Onboarding" - ], - "tags": [ - "Layer 1", - "Layer 2s", - "Tooling", - "DevRel", - "Live Coding", - "onboarding", - "DevRel", - "Layer 1", - "Layer 2s", - "Live Coding", - "Tooling" - ], - "language": "en", - "speakers": [ - "simon-emanuel-schmid", - "rob-stupay", - "abena" - ], - "eventId": "devcon-7", - "slot_start": 1731465900000, - "slot_end": 1731471300000, - "slot_roomId": "classroom-e", - "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk" - }, - "vector": [ 0, 0, 0, - 6, 0, 0, 0, @@ -877571,6 +878284,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -878023,6 +878738,55 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy", + "sourceId": "LUKWAM", + "title": "You know what’s going to get us from web2 to web3? Therapy", + "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g", + "track": "Coordination", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "thriving", + "mental health", + "future" + ], + "tags": [ + "future" + ], + "language": "en", + "speakers": [ + "simona-pop" + ], + "eventId": "devcon-7", + "slot_start": 1731487800000, + "slot_end": 1731488400000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA" + }, + "vector": [ 0, 0, 0, @@ -878034,6 +878798,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -878290,8 +879058,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -878312,13 +879078,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -878363,7 +879127,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -878413,7 +879176,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -878471,7 +879233,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -878851,7 +879612,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -878861,11 +879621,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -878876,53 +879634,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zk-email-fast-proofs-and-production-ready-account-recovery", - "sourceId": "WNQBQH", - "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery", - "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ZK", - "Email" - ], - "tags": [ - "Privacy", - "ZKP", - "Use cases of cryptography", - "client-side", - "2FA", - "Account Abstraction", - "Cryptography", - "Identity", - "Privacy", - "Recovery", - "Security", - "Use cases of cryptography", - "Zero-Knowledge", - "ZKP" - ], - "language": "en", - "speakers": [ - "aayush-gupta", - "sora-suegami" - ], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731470400000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY" - }, - "vector": [ 0, 0, 0, @@ -878933,7 +879644,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -879038,7 +879748,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -879381,6 +880090,51 @@ 0, 0, 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "your-intuition-antoine-flute-and-didgeridoo", + "sourceId": "B8SMVZ", + "title": "Your intuition Antoine flute and didgeridoo", + "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!", + "track": "Entertainment", + "type": "Music", + "expertise": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731389400000, + "slot_end": 1731391200000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY" + }, + "vector": [ 0, 0, 0, @@ -879390,6 +880144,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -879657,12 +880412,10 @@ 0, 0, 0, - 6, 0, 0, 0, 0, - 6, 0, 0, 0, @@ -879674,8 +880427,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -879690,7 +880441,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -879711,9 +880461,7 @@ 0, 0, 0, - 2, 0, - 2, 0, 0, 0, @@ -879737,7 +880485,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -879779,7 +880526,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -879829,7 +880575,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -880217,18 +880962,14 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -880241,38 +880982,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zk-in-rollups-full-validity-proving-on-the-op-stack", - "sourceId": "8J8Z7Q", - "title": "ZK in Rollups: Full Validity Proving on the OP Stack", - "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.", - "track": "Layer 2", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Layer 2s", - "Rollups", - "ZKP" - ], - "language": "en", - "speakers": [ - "uma-roy" - ], - "eventId": "devcon-7", - "slot_start": 1731582600000, - "slot_end": 1731583800000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY" - }, - "vector": [ 0, 0, 0, @@ -880280,7 +880989,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -880733,8 +881441,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -880747,9 +881457,54 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "zero-to-dapp", + "sourceId": "LUW7G9", + "title": "Zero To Dapp", + "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)", + "track": "Developer Experience", + "type": "Workshop", + "expertise": "Beginner", + "audience": "Developer", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Onboarding" + ], + "tags": [ + "Layer 1", + "Layer 2s", + "Tooling", + "DevRel", + "Live Coding", + "onboarding", + "DevRel", + "Layer 1", + "Layer 2s", + "Live Coding", + "Tooling" + ], + "language": "en", + "speakers": [ + "simon-emanuel-schmid", + "rob-stupay", + "abena" + ], + "eventId": "devcon-7", + "slot_start": 1731465900000, + "slot_end": 1731471300000, + "slot_roomId": "classroom-e", + "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk" + }, + "vector": [ 0, 0, 0, + 6, 0, 0, 0, @@ -881008,7 +881763,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -881054,7 +881808,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -881078,7 +881831,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -881087,7 +881839,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -881426,6 +882177,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -881485,6 +882237,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -881505,11 +882259,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -881554,6 +882310,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -881574,11 +882331,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -881591,54 +882346,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zkmpc-bring-public-auditability-into-mpc", - "sourceId": "XNN3XR", - "title": "ZKMPC: Bring public auditability into MPC", - "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "ZKP", - "MPC", - "collaboration", - "zk-snark", - "MPC", - "ZKP" - ], - "keywords": [ - "Collaborative", - "zk-SNARKs" - ], - "duration": 1399, - "language": "en", - "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188", - "sources_youtubeId": "aWQ8zzi1EAQ", - "sources_ipfsHash": "", - "sources_livepeerId": "", - "sources_streamethId": null, - "transcript_vtt": "No VTT link provided", - "transcript_text": "No transcript text provided", - "eventId": "devcon-7", - "slot_start": 1731407400000, - "slot_end": 1731409200000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ", - "resources_slides": null, - "speakers": [ - "task-ohmori", - "yusuke-nakae" - ] - }, - "vector": [ 0, 0, 0, @@ -881649,11 +882356,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -881711,6 +882418,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -882090,6 +882798,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -882099,9 +882808,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -882112,6 +882823,53 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "zk-email-fast-proofs-and-production-ready-account-recovery", + "sourceId": "WNQBQH", + "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery", + "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZK", + "Email" + ], + "tags": [ + "Privacy", + "ZKP", + "Use cases of cryptography", + "client-side", + "2FA", + "Account Abstraction", + "Cryptography", + "Identity", + "Privacy", + "Recovery", + "Security", + "Use cases of cryptography", + "Zero-Knowledge", + "ZKP" + ], + "language": "en", + "speakers": [ + "aayush-gupta", + "sora-suegami" + ], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731470400000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY" + }, + "vector": [ 0, 0, 0, @@ -882122,6 +882880,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -882227,6 +882986,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -882375,8 +883135,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -882453,7 +883211,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -882467,7 +883224,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -882852,10 +883608,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -882867,6 +883625,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -882881,6 +883641,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -882901,7 +883662,9 @@ 0, 0, 0, + 2, 0, + 2, 0, 0, 0, @@ -882925,6 +883688,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -882935,17 +883699,13 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -882957,48 +883717,6 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zkpassport-private-unforgeable-identity", - "sourceId": "K3GWST", - "title": "ZKpassport: Private Unforgeable Identity", - "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.", - "track": "Applied Cryptography", - "type": "Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ZK", - "NFC", - "Noir", - "PLONK" - ], - "tags": [ - "Privacy", - "Identity", - "Zero-Knowledge", - "noir", - "Identity", - "Privacy", - "Zero-Knowledge" - ], - "language": "en", - "speakers": [ - "michael-elliot", - "theo-madzou" - ], - "eventId": "devcon-7", - "slot_start": 1731484200000, - "slot_end": 1731486000000, - "slot_roomId": "classroom-a", - "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U" - }, - "vector": [ 0, 0, 0, @@ -883009,10 +883727,10 @@ 0, 0, 0, - 6, 0, 0, 0, + 2, 0, 0, 0, @@ -883062,6 +883780,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -883173,10 +883892,8 @@ 0, 0, 0, - 6, 0, 0, - 6, 0, 0, 0, @@ -883451,14 +884168,18 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -883471,6 +884192,38 @@ 0, 0, 0, + 0 + ] + }, + { + "session": { + "id": "zk-in-rollups-full-validity-proving-on-the-op-stack", + "sourceId": "8J8Z7Q", + "title": "ZK in Rollups: Full Validity Proving on the OP Stack", + "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.", + "track": "Layer 2", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Layer 2s", + "Rollups", + "ZKP" + ], + "language": "en", + "speakers": [ + "uma-roy" + ], + "eventId": "devcon-7", + "slot_start": 1731582600000, + "slot_end": 1731583800000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY" + }, + "vector": [ 0, 0, 0, @@ -883478,6 +884231,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -883750,7 +884504,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -883787,7 +884540,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -883837,7 +884589,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -883855,7 +884606,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -884213,6 +884963,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -884258,6 +885009,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -884281,6 +885033,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -884289,6 +885042,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -884300,11 +885055,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -884317,53 +885070,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zkproving-the-history-of-ethereum-in-real-time", - "sourceId": "TVNJ99", - "title": "zkProving the history of Ethereum in real time.", - "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Lightclient", - "type1", - "STARK" - ], - "tags": [ - "ZK-EVMs", - "ZKP", - "Zero-Knowledge", - "lightclient", - "type1", - "starks", - "Zero-Knowledge", - "ZK-EVMs", - "ZKP" - ], - "language": "en", - "speakers": [ - "jordi-baylina" - ], - "eventId": "devcon-7", - "slot_start": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -884662,7 +885372,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -884820,9 +885529,12 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -884832,6 +885544,56 @@ 0, 0, 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zkmpc-bring-public-auditability-into-mpc", + "sourceId": "XNN3XR", + "title": "ZKMPC: Bring public auditability into MPC", + "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "ZKP", + "MPC", + "collaboration", + "zk-snark", + "MPC", + "ZKP" + ], + "keywords": [ + "Collaborative", + "zk-SNARKs" + ], + "duration": 1399, + "language": "en", + "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188", + "sources_youtubeId": "aWQ8zzi1EAQ", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", + "eventId": "devcon-7", + "slot_start": 1731407400000, + "slot_end": 1731409200000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ", + "resources_slides": null, + "speakers": [ + "task-ohmori", + "yusuke-nakae" + ] + }, + "vector": [ 0, 0, 0, @@ -884842,6 +885604,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -885110,7 +885873,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -885173,7 +885935,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -885446,7 +886207,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -885574,6 +886334,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -885650,6 +886412,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -885657,13 +886423,9 @@ 0, 0, 0, - 2, - 2, - 2, 0, 0, 0, - 2, 2, 0, 0, @@ -885677,47 +886439,10 @@ 0, 0, 0, - 0 - ] - }, - { - "session": { - "id": "zoom-in-on-eof-stack-validation", - "sourceId": "YYGYGF", - "title": "Zoom in on EOF stack validation", - "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.", - "track": "Core Protocol", - "type": "Talk", - "expertise": "Expert", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EVM", - "EOF" - ], - "tags": [ - "Core Protocol", - "eof", - "Core", - "Protocol" - ], - "language": "en", - "speakers": [ - "andrei-maiboroda" - ], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731556800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg" - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -886169,6 +886894,93 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zkpassport-private-unforgeable-identity", + "sourceId": "K3GWST", + "title": "ZKpassport: Private Unforgeable Identity", + "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.", + "track": "Applied Cryptography", + "type": "Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZK", + "NFC", + "Noir", + "PLONK" + ], + "tags": [ + "Privacy", + "Identity", + "Zero-Knowledge", + "noir", + "Identity", + "Privacy", + "Zero-Knowledge" + ], + "language": "en", + "speakers": [ + "michael-elliot", + "theo-madzou" + ], + "eventId": "devcon-7", + "slot_start": 1731484200000, + "slot_end": 1731486000000, + "slot_roomId": "classroom-a", + "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U" + }, + "vector": [ + 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, @@ -886321,6 +887133,73 @@ 0, 0, 0, + 6, + 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, @@ -886451,7 +887330,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -886471,7 +887349,3100 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, + 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, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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": "zkproving-the-history-of-ethereum-in-real-time", + "sourceId": "TVNJ99", + "title": "zkProving the history of Ethereum in real time.", + "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Lightclient", + "type1", + "STARK" + ], + "tags": [ + "ZK-EVMs", + "ZKP", + "Zero-Knowledge", + "lightclient", + "type1", + "starks", + "Zero-Knowledge", + "ZK-EVMs", + "ZKP" + ], + "language": "en", + "speakers": [ + "jordi-baylina" + ], + "eventId": "devcon-7", + "slot_start": 1731474000000, + "slot_end": 1731475800000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 2, + 2, + 0, + 0, + 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0 + ] + }, + { + "session": { + "id": "zoom-in-on-eof-stack-validation", + "sourceId": "YYGYGF", + "title": "Zoom in on EOF stack validation", + "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.", + "track": "Core Protocol", + "type": "Talk", + "expertise": "Expert", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EVM", + "EOF" + ], + "tags": [ + "Core Protocol", + "eof", + "Core", + "Protocol" + ], + "language": "en", + "speakers": [ + "andrei-maiboroda" + ], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731556800000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg" + }, + "vector": [ + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 2, 0, 0, 0, @@ -888359,6 +892330,10 @@ 0, 0, 0, + 0, + 0, + 0, + 0, 2, 0, 0, diff --git a/devcon-api/data/vectors/dictionary.json b/devcon-api/data/vectors/dictionary.json index e39feba0..2b791e69 100644 --- a/devcon-api/data/vectors/dictionary.json +++ b/devcon-api/data/vectors/dictionary.json @@ -18,7 +18,8 @@ "[CLS] EPF Day", "", "[CLS] Infinite Endgames by Ethereum Magicians", - "[CLS] Formal Verification Hangout, FV Team" + "[CLS] Formal Verification Hangout, FV Team", + "[CLS] ETH Escape - Speed Hacking Challenge" ], "speakers": [ "qi-su", @@ -320,6 +321,7 @@ "andres-forigua", "william-martinez", "mateo-sabogal", + "michael-okeeffe", "mike-neuder", "stani-kulechov", "tomasz-stanczak", @@ -569,7 +571,6 @@ "jack-chuma", "alvaro", "shinya-mori", - "naveen-durvasula", "muhammad-noor", "isaac-patka", "kelsie-nabben", @@ -581,6 +582,9 @@ "rene-reinsberg", "francesco", "afra-zhao-wang", + "michael-lewellen", + "neville-grech", + "pietro-carta", "mercy-boma-naps-nkari", "zarathustra", "michal-zajac", From 665453f9a5afecce450db65f5e73cbf0e14949c2 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 13 Nov 2024 11:40:53 +0700 Subject: [PATCH 17/17] [skip deploy] PUT /sessions/zk-email-fast-proofs-and-production-ready-account-recovery --- ...and-production-ready-account-recovery.json | 27 ++++++++++++------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/devcon-api/data/sessions/devcon-7/zk-email-fast-proofs-and-production-ready-account-recovery.json b/devcon-api/data/sessions/devcon-7/zk-email-fast-proofs-and-production-ready-account-recovery.json index 4e689d76..592c3c77 100644 --- a/devcon-api/data/sessions/devcon-7/zk-email-fast-proofs-and-production-ready-account-recovery.json +++ b/devcon-api/data/sessions/devcon-7/zk-email-fast-proofs-and-production-ready-account-recovery.json @@ -9,10 +9,6 @@ "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "ZK", - "Email" - ], "tags": [ "Privacy", "ZKP", @@ -29,14 +25,27 @@ "Zero-Knowledge", "ZKP" ], - "language": "en", - "speakers": [ - "aayush-gupta", - "sora-suegami" + "keywords": [ + "ZK", + "Email" ], + "duration": 1518, + "language": "en", + "sources_swarmHash": "", + "sources_youtubeId": "YvzdNMpynZM", + "sources_ipfsHash": "", + "sources_livepeerId": "", + "sources_streamethId": null, + "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734245e9dbb7a90e18aa264.vtt", + "transcript_text": " Today we'll mostly be talking about zkEmail, new applications, and production-ready account recovery. I'm Ayush. I'm Soran. And most of this work was only made possible because of this incredible team of folks we have working with us. So huge shout out to them. So we'll start by mostly going over the basics. What is ZK email? How does it work? Then we'll dive a little bit into how you can make proofs really easily. And we'll discuss a new registry in SDK that lets you do that. And we'll try to expand the possibilities for how you think ZK email proofs can be used in reality. Finally, we'll talk about account recovery and how you can generally have email-triggered transactions on-chain. And last, we'll talk about dev tooling. All the different ways that we've put together tools for people to build these kinds of proofs really easily into existing apps. So to start with the basics, what is ZK email? The idea is that emails are signed according to the DKIM protocol, an RSA signature of the SHA-256 of the content of the email. This is applied to every single email sent or received since 2017, usually used for spam filtration, but we prove this inside of a ZK proof and add selective disclosure and parsing. This means that we can get proofs of emails where we can get privacy, as in we can hide or reveal whatever we want. We get provenance. We can verify the data from the Web2 services mail server directly, and it's portable. We can verify it directly on chain, on any chain that can verify these proofs. You can imagine the simplest intuition for this is something like whistleblowing. We take an email you've already received and we redact different parts of the email and then we prove that the email was still valid or sent by the source. But you can do much more than this. For instance, zkp2p builds marketplaces on top of these emails. One example is a domain marketplace. The idea is that you can take any Namecheap domain that you own, and you can list it on this marketplace, and when you sell the domain to somebody, aka you transfer it to them, both of you receive a confirmation email from Namecheap automatically. If you prove that confirmation email on-chain, you can then unlock escrowed money directly to pay for that domain. This is quite compelling, and the idea that you can interoperate these Web2 assets or things in the real world with things on-chain is extremely compelling, and how can we get more of these? So our idea was, what if we made it really, really easy for somebody to create new proofs and update those proofs? So we'll talk a little bit about how this can be applied to general proof infrastructure in a couple of different ways. A registry that lets you reuse proofs that other people have already defined and define new ones very easily. An SDK that lets you use them very easily in your application. And finally, some inspiration on what are some apps that people are actually building with this. So one of the main problems with ZK development today is that an app developer who's trying to build something related to their email should not have to think about the nitty-gritty details of which proof system they're using and the different trade-offs and different systems. So the idea is you can abstract this all away. You just define a sort of a blueprint, like, oh, I want to prove that I was rejected from giving a DevCon talk, for instance. And then if I define this kind of blueprint, anybody can use it without having to think of the proof system that's happening in the background. How does this work? The idea is you can create new patterns very easily. For instance, after naming your pattern and uploading a sample email, we can automatically parse out the relevant information from that email to help define this new kind of pattern. For instance, we can take out the sender domain automatically or things like the email length of the header or the body. Then we have this nice feature where because we want to define a regex to extract specific information from within that email, we automatically throw an AI on top of that raw email data and define that regex for users. We found that historically this has been a bit of a roadblock because having to adapt regexes to odd different kinds of email templates is often not a very intuitive task, but we're hoping this makes it super easy for anyone to define a new kind of proof with no relevant ZK or necessarily even parsing experience. And finally, it'll give you a configuration like this. This is a decent amount of text, but the main thing to take away from this is that it's only about 20 or 25 lines. This defines all of your regexes, where they occur, and who the email was sent from, and other metadata about it. But this is a full encapsulation and definition of your proof. Then in the background, we can automatically compile this to all the proof systems that we listed. Right now we have Sircom and Noir Incoming and also ZKVMs. And once it's completed, the compilation is completed, we automatically will deploy an interface that anybody can use to create this proof. We see this kind of like almost like a bit of a Vercel. You can sort of create your proof and deploy it without having to think about any of the infrastructure behind the scenes. Concretely, for instance, for the proof of DevCon rejection, you will automatically get an interface for you where you can automatically sign in with your email and then it will fetch the relevant emails that might possibly satisfy this proof. We can filter those emails entirely client-sized so that our server never sees those emails, and then let the user choose the proof they want to select to make a proof of. In this case, for instance, for GitHub, for DevCon, you can choose one of the specific DevCon rejection emails. For GitHub, you could choose, for instance, a GitHub username email to let you prove your GitHub username. Finally, the proof can happen in the background, and you can share that proof out to whoever you want to share. And we also show you the metadata very clearly and even let you look at the raw proof. The idea is that once we have these kinds of definitions, we can expand this even one step further. We can also kind of treat it like a bit of a GitHub, where each of these configurations can be edited and modified by other people, and you maintain a version history. So for instance, you can imagine that each of these patterns come with versions depending on email templates as they change, or users as they want to parse different kinds of things. And if you decide, hey, I don't like this pattern, I want to replace it with a different one, say I want to take my DevCon rejection email, and instead I want to prove DevCon acceptance, I can just fork it, change that value, and recompile it. And so we see these kinds of flows that developers are very used to also being useful for general people to be able to create these new kinds of proofs. You can try this out live if you go to registry.zk.email. We've put a QR code up. You can define a new proof by logging in and then creating a new pattern or trying any of the existing ones within the interface. Note that there will probably be a decent amount of load as all the folks in the audience try this, but we will have a workshop tomorrow where we go through detail, step-by-step, how exactly to do this. Now, if you want to integrate this into an actual application, again, you don't need to read the code, but just the idea that this can just be three or four lines, someone can just define, this is the kind of blueprint that I want to prove within my app. In this case, the DevCon rejection proof. They can say if they want to be local or not, and then they can, again you don't have to read the code, but they can just generate the proof and verify it on-chain if they want without having to think about the proof system. We've seen people build a lot of really exciting stuff with just this primitive. For instance, folks have built proof of DocuSign or HelloSign where you prove you signed some document with some title from somebody. You can prove you took a flight to or from somewhere and only reveal where you took it from and the destination. Someone created this proof where you can prove you're part of a Slack workspace. You can now start seeing how these things might start combining. You can build a system where you prove you're part of an organization on Slack, and then you automatically get reimbursed for your flights by proving you took them. And as people start realizing, oh, you can bolt these things together, you can build actually interesting systems on chain where you combine different facets of ideas or identities or actions we've taken in the real world. People have also proved, for instance, you've exported your LinkedIn data, which they then sell to, for instance, OpenAI to train on. You can then prove you exported all of your OpenAI chat data and then sell it to, for instance, Anthropic. You can also prove you automatically resolve the GitHub issue and then automatically disperse contributors for their contributions. John did this fun proof where you can prove you ordered a Pad Thai in Thailand where you basically show you have a grab receipt which has the word Pad Thai on it and a location that's in Thailand. And of course, you can prove that your proposal was rejected from DEF CON. So now that we have all of these basic concepts around how you can make proofs of emails that you've received in your inbox, one might imagine that you can also make proofs directly on chain. So far, we've just talked about identity that already exists in Web 2.0. But emails, you can imagine, are an interesting interface to actually interact with on-chain. So far we've just talked about parts of your identity that already exist in Web2, but emails you can imagine are an interesting interface to actually interact with on-chain apps directly. So concretely, how might you get this new kind of email trigger transaction? Well the idea is that instead of doing what we were doing earlier where you log in with email for instance and you select one to make a proof of, you instead send an email to trigger a transaction on-chain. This is quite interesting because now you can have a smart contract that's directly gated just by a sent email. This primitive is quite powerful. You can build things like account recovery, for instance, where you add emails as wallet guardians directly on your existing smart accounts. Things like email signers, where you can add an email directly on your multi-sig and have that approve transactions, for instance, as a 2FA, or for folks who don't have EOA wallets to be able to still approve transactions. You can log in with emails. This is something folks have wanted in the ecosystem for a very long time. But the idea that you can interact with, for average, application or crypto app just by logging in with your email and then using that to authorize an ephemeral session key. Or an email wallet where you can receive assets directly to email addresses even if they've never signed up. But today, we'll mostly focus on, I guess to start with, exactly how we can do these kinds of smart contracts with emails. So for instance, the flow here is that users can receive some email asking them to trigger some kind of transaction. And by replying to it, they can initiate that transaction on-chain. They will receive an email kind of like this. We've moved the actual value that's getting approved to the subject, so it's easy for you to read. But the idea is that you would receive a command kind of like recover account eth address from old owner eth address to new owner eth address. In reality, users would just see a simulation in their email, not this text, but we've put it here so it's easy to read. And the idea is that by replying to this email, they're effectively signing this message, which can then be used to send on-chain. Flow here is that a user will try to trigger some sort of transaction, a relayer will send them an email. When they reply to that email, action is then sent directly by the relayer on-chain as they make a ZK proof of that action. One of the cool properties of this is the idea that we have this account code for both privacy and decentralization. You can kind of see, again, we've elevated it into the subject here, but normally this would just be embedded into the body where the user doesn't have to think about it. But what is the point of this long hex string? It's not really private key or something we're necessarily exactly used to. And anyway, it's abstracted away from the user. But it is nice because this value gives us direct email address privacy on-chain. We never reveal the email address, we only ever reveal a hash of the email address and that code. We can also prove availability to the user in this email. That is, concretely, we can ensure that the access to the user's account cannot be withheld by us going malicious, because as long as they have the account code, they can still transact with that email contract. And finally, it allows for relayer decentralization. Anyone can run this kind of system, can run email servers that send out emails, receive replies, and then trigger transactions on-chain. You can imagine this can happen via email replies, as it does right now, or even directly via Google logins. The difference between these is mostly basic security. For instance, on the left side, you can show concrete simulation data to the user of what they're signing. For Google sign-in, it's more like a blind sign-in and a blind signature. But the idea is that applications can choose whatever they want based on what is most convenient for them. Okay, so from now, amongst the products using email trigger transactions, here we introduce the details of the email account recovery. So in short, using email account recovery, you can specify anywhere with an email address as a guardian for your wallet. And when you lose access to your private key, this guardian can help recover your account just by sending emails. And in this way, this achieves a similar UX as a bank account or PayPal, such that users can reset passwords from their email account. And we also believe the combination of the email account recovery with the PASC wallet makes a super easy wallet UX because PASC allows users to sign transactions through the face ID and so on. And when users lose a device, users can use email account recovery to recover users recovery user's account on the other device. So from now, we explain the details of how email account details of how email account recovery works with showing the UI of the email account recovery feature in the Clive wallet we are building now. So in the first step, the user configures recovery settings, such as Guardian information. So in the Clave URL, the user just needs to specify the Guardian's email address, like this one. So in the second step, the Guardian will accept this request. So the Guardian will receive an email like this one from the relayer, and if the guardian can approve this request, the guardian just need to reply to this email. And the guardian will finally receive a confirmation email like this one. And in this process, our guardian actually generates ZK proof of the guardian's email, and send this email proof on-chain to register Guardian's address. And once the user loses access to the private key, we actually start the recovery process. So in this process, the user puts the Guardian's email address again, and the Guardian will receive an email from the layer in the same way. And if the Guardian approves this recovery request, the Guardian will reply to this email and receive the confirmation email. And in this process, the layer similarly generates ZK proof of the Guardian's email. In the final step, the Guardian, the wallet user, can complete this recovery request once more than a threshold number of the Guardian's upload recovery request. However, there is a time delay before completing this recovery request. And this improves the security when the Guardian's email account is hacked, because the wallet user can cancel recovery requests if the email account is hacked. So in this way, we can keep the security and the accessibility of the user's account as long as the user can access to the private key or the Guardian's email account is honest. Sweet. So we have those account recovery deployments audited and live on mainnet for both Clave, which we'll roll out in the Clave wallet over the next week for PASCII wallets, and also in our recovery UI for safes. But this can be larger than just a couple of wallets. The idea is that any smart wallet can integrate this into their wallet. And so we've created a bunch of dev tooling to make it really easy for anybody to use these kinds of proofs. Concretely, for instance, a recovery module is a 7579 compatible smart account standard. This means any wallet is really easy to integrate with this specific account recovery. And even if you're not 7579 compatible, it's still quite easy to add account recovery to your wallet. We have a set of very simple APIs that users can call. Again, you don't need to read all the details here. But to trigger each of these requests, you can simply hit each of those APIs, and your own wallet or your own application can trigger any of these kinds of transactions directly. And finally, installing it to any kind of wallet in a front-end is also very easy. Again, you don't have to read the exact code, but just the idea that installation is just five lines in, for instance, the permissionless JS smart wallet creation interface. You can read more about it on our docs on the right side, and we'll have more links at the end. If you want to define your own kinds of proofs, not account recovery, but say any of the other application ideas, you can define your own kind of pattern in Solidity directly. Here we show that you can say something like recover account ETH address to new owner ETH address. Once you've defined this kind of Solidity code, you can then hit any API that any relayer has deployed. The API request looks kind of like this. Again, the main thing here is it's just about 10 lines, and it'll automatically handle sending the emails for you, getting the response, making the ZK proof, and sending it on-chain. You can see, again, these docs for how exactly to build with this dev tooling over here, and we'll have a workshop tomorrow where we go over more of it in detail. So, for instance, you can imagine this abstraction can be used to build account recovery, email signers, login, and the email wallet primitive we talked about in the beginning, but we're excited for folks to explore with these kind of email trigger transactions to build more different kinds of things. So just to quickly recap, we went over the very basics of how ZK email works and simple kinds of proofs you can make, how to make new kinds of proofs very easily and access them from a shared registry. Then, switching from making proofs of received emails to making new kinds of proofs very easily and access them from a shared registry, then switching from making proofs of received emails to making proofs of sent emails, we went over how you can do email trigger transactions, and then account recovery, and finally how we've made this really easy for new folks to either directly use or integrate directly into their wallets or projects, etc. We're super excited to jam more with folks. If people want, we'll have some booths specified on the left. You can catch us there after this talk and also over the next two days. And if you want to learn more about how to specifically use these tools in your applications, we'll have a concrete workshop tomorrow at 1.30 p.m. where we go over how to actually integrate each of these things directly with help from the team who actually built it. Sweet. So if you want to read, see, or hear more, we recommend following our Twitter on the left side, looking at our home page in the middle on zk.email. And if you want to view an original copy of these slides, you can scan the QR code on the rightmost side. Sweet. Thank you for coming, and we'll take some questions. Sweet. Thank you, Ayush and Sora. That was a very interesting talk, by the way, right? Yeah, I like to see ZKPs being used for something else rather than ZK all apps, right? And it makes us both Web 2 and Web 3. So we have some time for Q&A. So how about we take the first one? So it says, what zkp framework you are using and why? Yeah, it's a good question. So we've used and benchmarked all of the frameworks that we kind of listed in the beginning. We have versions in Surcom and now Noir and also now in ZKVMs like SP1 and RISC-0. We generally, so because most of these things are happening on, for instance, mainnets, we want to make sure that there's both high security and extremely high speed. So currently we use Surcom on the server side and also on the client side just because it's kind of the main one that's very mainnet ready right now, and also can prove extremely fast on the server side, and within like five to ten seconds usually for most of the proofs we're talking about. But we intend to work closer with Noir to get those client side proofs working in Noir, and closer with the ZKVMs to get much more extensible proofs on the server side. Yeah, that makes sense. Actually, by the way, you can upvote the questions so that we can see those that you upvoted first here on the screen. So maybe if we take the second one, would trusted setup ceremonies ever be required? If so, when? Yeah, so this sort of depends on the exact proof system you're using. If you're using the CIRCOM proof system we have in production right now, then yes, you will need to do a trusted setup. However, if you use the Noir system on the client side we're moving to, or the ZKVM system on the server side that we also have, then you won't need to do a trusted setup for that specific circuit. Yeah, so we have two votes. Yeah, maybe this question. So is there any prerequirements for an email to be ZK-approved? Not really. Any email you send to receive can usually be ZK-approved because all emails require this DKIM signature to go through spam filtration. There are some restrictions, like, for instance, Hotmail is not exactly pursuant to the standards, so something that you can't access a two-email within a Hotmail is not exactly pursuant to the standards, so some things that you can't access to email within a Hotmail email. But in general, almost every email that you send or receive can be approved. Okay, gotcha. I think we've still got time for more questions. Yeah. Yeah, maybe this one, when we consider... I think we can see them also here. I guess the top one, is there a key rotation problem? Yeah, so the public keys that the verification actually happens with are rotated every maybe six months to two years. For some folks, it never rotates. The nice thing about this is that the smart contract that holds those keys is publicly auditable. Anybody can go in and say, yep, this is the key that my DNS is fetching as well. But yes, to relay those keys on publicly auditable. Anybody can go in and say, yep, this is the keys that my DNS is fetching as well. But yes, to relay those keys on-chain, there has to be some sort of a system of oracles. In our case, we use like a specific multi-sig in which all of the, like a bunch of autonomous computers are calculating those and putting it on-chain. You can also doubly verify TLS notary or TLS proxies to ensure that all those values are correct. The important thing here is that you can use a single public value, that DNS value, to verify private data. And that public value is auditable. So the idea is that if there was ever some fault, somebody pushed malicious keys, there are enough time locks built into the system and also ways to stop it or ways to override those key registries for each user that we think this is not actually that big of a problem in practice. That makes sense. Thank you for the detailed question. Yeah, so maybe what if we take this one? Since DKIM private keys for the whole domain rather than the percenter, presumably the security model relies and we don't see the question anymore. Yeah, so, so... I mean, I'm just repeating the question for the live stream so that people, yeah, so the origin MTA preventing sender spoofing within the domain. Yeah, so the idea here is that yes, because you're only verifying the signature from the domain, you are trusting that that specific domain is, in fact, disambiguating senders correctly. The nice thing here is that most email providers that most people use, like Gmail, Outlook, iCloud, et cetera, definitely have this in by default because it would be very bad if they didn't. But we have noticed that some folks don't. So, for instance, we disable most .edu domains from most of these models because often they don't have very good parsing of this kind of which sender exactly in the domain sent that email. But in most cases, for instance, that you receive an email from Twitter or DevCon or whatever, usually you can constrain exactly the email address that sent it, and that's usually good enough. And they're usually using something like Google Workspace, so it's usually good enough, and they're usually using something like Google Workspace, so it's usually possible. And in the context of the email trigger transactions, while this depends on the private key of the specific email or Deacon or server like Gmail, we believe this achieves a better trade-off between the UX and the security. Thank you. So I think we are on time. Please thank again Ayush and Sora and please applaud them for their talk.", "eventId": "devcon-7", "slot_start": 1731468600000, "slot_end": 1731470400000, "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY" + "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY", + "resources_slides": null, + "speakers": [ + "aayush-gupta", + "sora-suegami" + ] } \ No newline at end of file