<html><head><title>2023-07-21 Codex weekly</title><metacharSet="utf-8"/><metaname="viewport"content="width=device-width, initial-scale=1.0"/><metaproperty="og:title"content="2023-07-21 Codex weekly"/><metaproperty="og:description"content="Codex update 07/12/2023 to 07/21/2023 § Overall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc… Our main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year."/><metaproperty="og:image"content="https://roadmap.logos.co/static/og-image.png"/><metaproperty="og:width"content="1200"/><metaproperty="og:height"content="675"/><linkrel="icon"href="../../static/icon.png"/><metaname="description"content="Codex update 07/12/2023 to 07/21/2023 § Overall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc… Our main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year."/><metaname="generator"content="Logos Roadmaps"/><linkrel="preconnect"href="https://fonts.googleapis.com"/><linkrel="preconnect"href="https://fonts.gstatic.com"/><linkhref="../../index.css"rel="stylesheet"type="text/css"spa-preserve/><linkhref="https://cdn.jsdelivr.net/npm/katex@0.16.0/dist/katex.min.css"rel="stylesheet"type="text/css"spa-preserve/><linkhref="https://fonts.googleapis.com/css2?family=IBM Plex Mono&family=sans-serif:wght@400;700&family=sans-serif:ital,wght@0,400;0,600;1,400;1,600&display=swap"rel="stylesheet"type="text/css"spa-preserve/><scriptsrc="../../prescript.js"type="application/javascript"spa-preserve></script><scripttype="application/javascript"spa-preserve>constfetchData=fetch(`../../static/contentIndex.json`).then(data=>data.json())</script></head><bodydata-slug="codex/updates/2023-07-21"><divid="quartz-root"class="page"><divid="quartz-body"><divclass="left sidebar"><h1class="page-title"><ahref="../..">Logos Collective Project Roadmaps</a></h1><divclass="spacer mobile-only"></div><divclass="search"><divid="search-icon"><p>Search</p><div></div><svgtabIndex="0"aria-labelledby="title desc"role="img"xmlns="http://www.w3.org/2000/svg"viewBox="0 0 19.9 19.7"><titleid="title">Search</title><descid="desc">Search</desc><gclass="search-path"fill="none"><pathstroke-linecap="square"d="M18.5 18.3l-5.4-5.4"></path><circlecx="8"cy="8"r="7"></circle></g></svg></div><divid="search-container"><divid="search-space"><inputautocomplete="off"id="search-bar"name="search"type="text"aria-label="Search for something"placeholder="Search for something"/><divid="results-container"></div></div></div></div><divclass="darkmode"><inputclass="toggle"id="darkmode-toggle"type="checkbox"tabIndex="-1"/><labelid="toggle-label-light"for="darkmode-toggle"tabIndex="-1"><svgxmlns="http://www.w3.org/2000/svg"xmlnsXlink="http://www.w3.org/1999/xlink"version="1.1"id="dayIcon"x="0px"y="0px"viewBox="0 0 35 35"style="enable-background:new 0 0 35 35;"xmlSpace="preserve"><title>Light mode</title><pathd="M6,17.5C6,16.672,5.328,16,4.5,16h-3C0.672,16,0,16.672,0,17.5S0.672,19,1.5,19h3C5.328,19,6,18.328,6,17.5zM7.5,26c-0.414,0-0.789,0.168-1.061,0.439l-2,2C4.168,28.711,4,29.086,4,29.5C4,30.328,4.671,31,5.5,31c0.414,0,0.789-0.168,1.06-0.44l2-2C8.832,28.289,9,27.914,9,27.5C9,26.672,8.329,26,7.5,26zM17.5,6C18.329,6,19,5.328,19,4.5v-3C19,0.672,18.329,0,17.5,0S16,0.672,16,1.5v3C16,5.328,16.671,6,17.5,6zM27.5,9c0.414,0,0.789-0.168,1.06-0.439l2-2C30.832,6.289,31,5.914,31,5.5C31,4.672,30.329,4,29.5,4c-0.414,0-0.789,0.168-1.061,0.44l-2,2C26.168,6.711,26,7.086,26,7.5C26,8.328,26.671,9,27.5,9zM6.439,8.561C6.711,8.832,7.086,9,7.5,9C8.328,9,9,8.328,9,7.5c0-0.414-0.168-0.789-0.439-1.061l-2-2C6.289,4.168,5.914,4,5.5,4C4.672,4,4,4.672,4,5.5c0,0.414,0.168,0.789,0.439,1.06L6.439,8.561zM33.5,16h-3c-0.828,0-1.5,0.672-1.5,1.5s0.672,1.5,1.5,1.5h3c0.828,0,1.5-0.672,1.5-1.5S34.328,16,33.5,16zM28.561,26.439
<p>Overall we continue working in various directions, distributed testing, marketplace, p2p client, research, etc…</p>
<p>Our main milestone is to have a fully functional testnet with the marketplace and durability guarantees deployed by end of year. A lot of grunt work is being done to make that possible. Progress is steady, but there are lots of stabilization and testing & infra related work going on.</p>
<p>We’re also onboarding several new members to the team (4 to be precise), this will ultimately accelerate our progress, but it requires some upfront investment from some of the more experienced team members.</p>
<li>Onboarding Balázs as our ZK researcher/engineer</li>
<li>Continued research in DAS related topics
<ul>
<li>Running simulation on newly setup infrastructure</li>
</ul>
</li>
<li>Devised a new direction to reduce metadata overhead and enable remote verification <ahref="https://github.com/codex-storage/codex-research/blob/master/design/metadata-overhead.md"class="external">metadata-overhead.md</a></li>
<h3id="cross-functional-combination-of-devopstestingdevelopment">Cross-functional (Combination of DevOps/Testing/Development):<aaria-hidden="true"tabindex="-1"href="#cross-functional-combination-of-devopstestingdevelopment"class="internal"> §</a></h3>
<ul>
<li>Fixed discovery related issues.</li>
<li>Planned Codex Demo update for the Logos event and prepared environment for the demo.</li>
<li>Described requirements for Dist Tests logs format.</li>
<li>Configured new Logs shipper and Grafana in Dist-Tests cluster.</li>
<li>Dist Tests logs adoption requirements - Updated log format for Kibana compatibility.</li>
<li>Hetzner Dedicated server was configured.</li>
<li>Set up Hetzner StorageBox for local backup on Dedicated server.</li>
<li>Configured new Logs shipper in Dist-Tests cluster.</li>
<li>Setup Grafana in Dist-Tests cluster.</li>
<li>Created a separate codex-contracts-eth Docker image for Dist-Tests.</li>
<li>Setup Ingress Controller in Dist-Tests cluster.</li>
<p>We’ve explored VDI for rollups ourselves in the last week, curious to know your thoughts</p>
</blockquote>
<olstart="2">
<li>dryajov <em>—</em> 07/25/2023 1:28 PM</li>
</ol>
<blockquote>
<p>It depends on what you mean, from a high level (A)VID is probably the closest thing to DAS in academic research, in fact DAS is probably either a subset or a superset of VID, so it’s definitely worth digging into. But I’m not sure what exactly you’re interested in, in the context of rollups…</p>
</blockquote>
<ol>
<li>
<p>zk_id <em>—</em> 07/25/2023 3:28 PM</p>
<p>The part of the rollups seems to be the base for choosing proofs that scale linearly with the amount of nodes (which makes it impractical for large numbers of nodes). The protocol is very simple, and would only need to instead provide constant proofs with the Kate commitments (at the cost of large computational resources is my understanding). This was at least the rationale that I get from reading the paper and the conversation with Bunz, one of the founders of the Espresso shared sequencer (which is where I found the first reference to this paper). I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal. You still would need the sampling for the light clients though, of course.</p>
</li>
<li>
<p>dryajov <em>—</em> 07/25/2023 8:31 PM</p>
<blockquote>
<p>I guess my main open question is why would you do the sampling if you can do VID in the context of blockchains as well. With the proofs of dispersal on-chain, you wouldn’t need to do that for the agreement of the dispersal.</p>
</blockquote>
<p>Yeah, great question. What follows is strictly IMO, as I haven’t seen this formally contrasted anywhere, so my reasoning can be wrong in subtle ways.</p>
<ul>
<li>(A)VID - <strong>dispersing</strong> and storing data in a verifiable manner</li>
<p>tl;dr Sampling allows light nodes to protect against dishonest majority attacks. In other words, a light node cannot be tricked to follow an incorrect chain by a dishonest validator majority that withholds data. More details are here - <ahref="https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html"title="https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html"class="external">data-availability-checks.html</a> ------------- First, DAS implies (A)VID, as there is an initial phase where data is distributed to some subset of nodes. Moreover, these nodes, usually the validators, attest that they received the data and that it is correct. If a majority of validators accepts, then the block is considered correct, otherwise it is rejected. This is the verifiable dispersal part. But what if the majority of validators are dishonest? Can you prevent them from tricking the rest of the network from following the chain?</p>
<h2id="dealing-with-dishonest-majorities">Dealing with dishonest majorities<aaria-hidden="true"tabindex="-1"href="#dealing-with-dishonest-majorities"class="internal"> §</a></h2>
<p>This is easy if all the data is downloaded by all nodes all the time, but we’re trying to avoid just that. But lets assume, for the sake of the argument, that there are full nodes in the network that download all the data and are able to construct fraud proofs for missing data, can this mitigate the problem? It turns out that it can’t, because proving data (un)availability isn’t a directly attributable fault - in other words, you can observe/detect it but there is no way you can prove it to the rest of the network reliably. More details here <ahref="https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding"title="https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding"class="external">A-note-on-data-availability-and-erasure-coding</a> So, if there isn’t much that can be done by detecting that a block isn’t available, what good is it for? Well nodes can still avoid following the unavailable chain and thus be tricked by a dishonest majority. However, simply attesting that data has been publishing is not enough to prevent a dishonest majority from attacking the network. (edited)</p>
</li>
<li>
<p>dryajov <em>—</em> 07/25/2023 9:06 PM</p>
<p>To complement, the relevant quote from <ahref="https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding"title="https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding"class="external">A-note-on-data-availability-and-erasure-coding</a>, is:</p>
<blockquote>
<p>Here, fraud proofs are not a solution, because not publishing data is not a uniquely attributable fault - in any scheme where a node (“fisherman”) has the ability to “raise the alarm” about some piece of data not being available, if the publisher then publishes the remaining data, all nodes who were not paying attention to that specific piece of data at that exact time cannot determine whether it was the publisher that was maliciously withholding data or whether it was the fisherman that was maliciously making a false alarm.</p>
</blockquote>
<p>The relevant quote from from <ahref="https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html"title="https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html"class="external">data-availability-checks.html</a>, is:</p>
<blockquote>
<p>There is one gap in the solution of using fraud proofs to protect light clients from incorrect state transitions: What if a consensus supermajority has signed a block header, but will not publish some of the data (in particular, it could be fraudulent transactions that they will publish later to trick someone into accepting printed/stolen money)? Honest full nodes, obviously, will not follow this chain, as they can’t download the data. But light clients will not know that the data is not available since they don’t try to download the data, only the header. So we are in a situation where the honest full nodes know that something fishy is going on, but they have no means of alerting the light clients, as they are missing the piece of data that might be needed to create a fraud proof.</p>
</blockquote>
<p>Both articles are a bit old, but the intuitions still hold.</p>
</li>
</ol>
<p>July 26, 2023</p>
<olstart="6">
<li>
<p>zk_id <em>—</em> 07/26/2023 10:42 AM</p>
<p>Thanks a ton @dryajov ! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw. Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.</p>
</li>
<li>
<p><em>[<em>10:45 AM</em>]</em></p>
<p>The dishonest majority is critical scenario for Nomos (essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs</p>
</li>
<li>
<p>zk_id</p>
<p>Thanks a ton@dryajov! We are on the same page. TBH it took me a while to get to this point, as it’s not an intuitive problem at first. The relationship between the VID and the DAS, and what each is for is crucial for us, btw.Your writing here and your references give us the confidence that we understand the problem and are equipped to evaluate the different solutions. Deeply appreciate that you took the time to write this, and is very valuable.</p>
<p>The dishonest majority is critical scenario for Nomos(essential part of the whole sovereignty narrative), and generally not considered by most blockchain designs</p>
<p>dryajov <em>—</em> 07/26/2023 4:43 PM</p>
<p>Yes, I’d argue it is crucial in a network with distributed validation, where all nodes are either fully light or partially light nodes.</p>
</li>
<li>
<p><em>[<em>4:46 PM</em>]</em></p>
<p>Btw, there is probably more we can share/compare notes on in this problem space, we’re looking at similar things, perhaps from a slightly different perspective in Codex’s case, but the work done on DAS with the EF directly is probably very relevant for you as well</p>
</li>
</ol>
<p>July 27, 2023</p>
<olstart="12">
<li>
<p>zk_id <em>—</em> 07/27/2023 3:05 AM</p>
<p>I would love to. Do you have those notes somewhere?</p>
</li>
<li>
<p>zk_id <em>—</em> 07/27/2023 4:01 AM</p>
<p>all the links you have, anything, would be useful</p>
</li>
<li>
<p>zk_id</p>
<p>I would love to. Do you have those notes somewhere?</p>
<p>dryajov <em>—</em> 07/27/2023 4:50 PM</p>
<p>A bit scattered all over the place, mainly from @Leobago and @cskiraly @cskiraly has a draft paper somewhere</p>
</li>
</ol>
<p>July 28, 2023</p>
<olstart="16">
<li>
<p>zk_id <em>—</em> 07/28/2023 5:47 AM</p>
<p>Would love to see anything that is possible</p>
</li>
<li>
<p><em>[<em>5:47 AM</em>]</em></p>
<p>Our setting is much simpler, but any progress that you make (specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us</p>
</li>
<li>
<p>zk_id</p>
<p>Our setting is much simpler, but any progress that you make(specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us</p>
<p>dryajov <em>—</em> 07/28/2023 4:07 PM</p>
<p>Yes, we’re also working in this direction as this is crucial for us as well. There should be some result coming soon(tm), now that @bkomuves is helping us with this part.</p>
</li>
<li>
<p>zk_id</p>
<p>Our setting is much simpler, but any progress that you make(specifically in the computational cost of the polynomial commitments or alternative proofs) would be really useful for us</p>
<p>bkomuves <em>—</em> 07/28/2023 4:44 PM</p>
<p>my current view (it’s changing pretty often :) is that there is tension between:</p>
<ul>
<li>commitment cost</li>
<li>proof cost</li>
<li>and verification cost</li>
</ul>
<p>the holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for. we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that (and also based on what’s possible, there are external restrictions)</p>
</li>
</ol>
<p>July 29, 2023</p>
<olstart="21">
<li>
<p>bkomuves</p>
<p>my current view(it’s changing pretty often:) is that there is tension between:</p>
<ul>
<li>commitment cost</li>
<li>proof cost</li>
<li>and verification cost</li>
</ul>
<p>the holy grail which is the best for all of them doesn’t seem to exist. Hence, you have to make tradeoffs, and it depends on your specific use case what you should optimize for, or what balance you aim for.we plan to find some points in this 3 dimensional space which are hopefully close to the optimal surface, and in parallel to that figure out what balance to aim for, and then choose a solution based on that(and also based on what’s possible, there are external restrictions)</p>
<p>zk_id <em>—</em> 07/29/2023 4:23 AM</p>
<p>I agree. That’s also my understanding (although surely much more superficial).</p>
</li>
<li>
<p><em>[<em>4:24 AM</em>]</em></p>
<p>There is also the dimension of computation vs size cost</p>
</li>
<li>
<p><em>[<em>4:25 AM</em>]</em></p>
<p>ie the VID scheme (of the paper that kickstarted this conversation) has all the properties we need, but it scales n^2 in message complexity which makes it lose the properties we are looking for after 1k nodes. We need to scale confortably to 10k nodes.</p>
</li>
<li>
<p><em>[<em>4:29 AM</em>]</em></p>
<p>So we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is:</p>
<ul>
<li>Our rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol (and then run consensus on the aggregated signed proofs).</li>
<li>If we ever decide to change the design for the VID dispersal to be done by Base Layer leaders (in a multileader fashion), it can be distributed (rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.</li>
</ul>
</li>
</ol>
<p>August 1, 2023</p>
<olstart="26">
<li>
<p>dryajov</p>
<p>A bit scattered all over the place, mainly from@Leobagoand@cskiraly@cskiralyhas a draft paper somewhere</p>
<p>Leobago <em>—</em> 08/01/2023 1:13 PM</p>
<p>Note much public write-ups yet. You can find some content here:</p>
<p>We also have a few Jupiter notebooks but they are not public yet. As soon as that content is out we can let you know <imgsrc="https://discord.com/assets/da3651e59d6006dfa5fa07ec3102d1f3.svg"alt="🙂"/></p>
<p>The Codex team is busy building a new web3 decentralized storage platform with the latest advances in erasure coding and verification systems. Part of the challenge of deploying decentralized storage infrastructure is to guarantee that the data that has been stored and is available for retrieval from the beginning until</p>
<p>GitHub</p>
<p><ahref="https://github.com/codex-storage/das-research"class="external">das-research: This repository hosts all the …</a></p>
<p>This repository hosts all the research on DAS for the collaboration between Codex and the EF. - GitHub - codex-storage/das-research: This repository hosts all the research on DAS for the collabora…</p>
<p><imgsrc="https://images-ext-2.discordapp.net/external/DxXI-YBkzTrPfx_p6_kVpJzvVe6Ix6DrNxgrCbcsjxo/https/opengraph.githubassets.com/39769464ebae80ca62c111bf2acb6af95fde1b9dc6e3c5a9eb56316ea363e3d8/codex-storage/das-research?width=400&height=200"alt="GitHub - codex-storage/das-research: This repository hosts all the ..."/></p>
</li>
<li>
<p>zk_id</p>
<p>So we are at the moment most likely to use KZG commitments with a 2d RS polynomial. Basically just copy Ethereum. Reason is:</p>
<ul>
<li>Our rollups/EZ leader will generate this, and those are beefier machines than the Base Layer. The base layer nodes just need to verify and sign the EC fragments and return them to complete the VID protocol(and then run consensus on the aggregated signed proofs).</li>
<li>If we ever decide to change the design for the VID dispersal to be done by Base Layer leaders(in a multileader fashion), it can be distributed(rows/columns can be reconstructed and proven separately). I don’t think we will pursue this, but we will have to if this scheme doesn’t scale with the first option.</li>
</ul>
<p>dryajov <em>—</em> 08/01/2023 1:55 PM</p>
<p>This might interest you as well - <ahref="https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a"title="https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a"class="external">combining-kzg-and-erasure-coding-fc903dc78f1a</a></p>
<p>Medium</p>
<p><ahref="https://blog.subspace.network/combining-kzg-and-erasure-coding-fc903dc78f1a"class="external">Combining KZG and erasure coding</a></p>
<p>The Hitchhiker’s Guide to Subspace —Episode II</p>
<p><imgsrc="https://images-ext-2.discordapp.net/external/LkoJxMEskKGMwVs8XTPVQEEu0senjEQf42taOjAYu0k/https/miro.medium.com/v2/resize%3Afit%3A1200/0%2AKGb5QHFQEd0cvPeP.png?width=400&height=200"alt="Combining KZG and erasure coding"/></p>
</li>
<li>
<p><em>[<em>1:56 PM</em>]</em></p>
<p>This is a great analysis of the current state of the art in structure of data + commitment and the interplay. I would also recoment reading the first article of the series which it also links to</p>
</li>
<li>
<p>zk_id <em>—</em> 08/01/2023 3:04 PM</p>
<p>Thanks @dryajov @Leobago ! Much appreciated!</p>
</li>
<li>
<p><em>[<em>3:05 PM</em>]</em></p>
<p>Very glad that we can discuss these things with you. Maybe I have some specific questions once I finish reading a huge pile of pending docs that I’m tackling starting today…</p>
</li>
<li>
<p>zk_id <em>—</em> 08/01/2023 6:34 PM</p>
<p>@Leobago @dryajov I was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?</p>
</li>
<li>
<p>zk_id</p>
<p>@Leobago@dryajovI was playing with the DAS simulator. It seems the results are a bunch of XML. Is there a way so I visualize the results?</p>
<p>Leobago <em>—</em> 08/01/2023 6:36 PM</p>
<p>Yes, checkout the visual branch and make sure to enable plotting in the config file, it should produce a bunch of figures <imgsrc="https://discord.com/assets/da3651e59d6006dfa5fa07ec3102d1f3.svg"alt="🙂"/></p>
</li>
<li>
<p><em>[<em>6:37 PM</em>]</em></p>
<p>You might find also some bugs here and there on that branch <imgsrc="https://discord.com/assets/b45af785b0e648fe2fb7e318a6b8010c.svg"alt="😅"/></p>
