Add ZKLVS info (#200)

add zklvs description and diagrams

content/2024-11-08-ZTEE2.mdx

@@ -129,15 +129,23 @@ Fortunately, there are already several designs which are ***partially*** open. [
 
 #### Partial Openness
 
+
 Another approach recognises that the march to a sufficiently powerful open hardware “stack” is a long and unpredictable one, and instead asks what we can do without opening everything up. The idea is to go as far as possible with only the RTL and netlist being public, using mathematical tooling to learn as much as possible from the information that is open.
+![image|690x205, 75%](/img/ZTEE/zklvs1.jpeg)
+
 One way ([proposed by Bunnie](https://www.bunniestudios.com/blog/2024/iris-infra-red-in-situ-project-updates/)) to do this is to **bound the density of logic** (i.e. number of transistors per unit of area) we should expect in different regions of the chip. We could rely on formal methods to achieve these bounds, but partial reliance on heuristics may also be a viable path. The reasoning behind these heuristics would be that there are large financial incentives to develop techniques to pack logic more tightly and to advertise such improvements instead of secretly developing them for the insertion of trojans. Sufficiently tight bounds would render large trojans detectable. Given how [small](https://link.springer.com/chapter/10.1007/978-3-642-40349-1_12) some (dopant-level) trojans can be, we would also need other techniques to force trojans to a detectable size. We cover this issue in more depth in the next section. The proof techniques for upper bounding logic density and lower bounding trojans still need to be developed so this should be considered a direction for exploration rather than an option today.^[If you are knowledgeable or interested in working on (or funding) these problems reach out to us or Bunnie directly.]
+![image|690x379, 75%](/img/ZTEE/zklvs2.jpeg)
+
 
 Other ideas require the fab to select special actors to be given access to the GDS and PDK. These chosen verifiers can use the GDS and PDK to make public statements that link an image of a chip to the netlist. These statements would actually consist of two claims: 
 
 - The verifier is in possession of a GDS and PDK such that `GDS==PlaceRoute(netlist, PDK)`
 - The verifier is in possession of an image such that `compare(image, GDS) == true` where `compare` is a public algorithm
 
-Of course these claims can simply be signed statements posted publicly from reputable actors, but we can also rely on zero-knowledge proofs (e.g. SNARKS^[we could technically use SH for this as well, but this feels like turtles all the way down]) which provide much better trust assumptions. One challenge here is that `PlaceRoute` is given by the EDA software which is typically closed source. Since a malicious `PlaceRoute` can be used to insert a trojan, the EDA must be publicly auditable in order for this scheme to work. In effect, we are trading off the challenge of open sourcing the EDA with that of getting an open PDK.If the image is published along with the proofs tying it to the netlist, the image can later be used by other actors as a reference to verify other chips.
+![image|690x264, 75%](/img/ZTEE/zklvs3.jpeg)
+
+
+There are several techniques we can use to do this. The most basic is simply to use a quorum of actors who are trusted by the fab with access to the GDS and PDK. The fab selecting the committee of verifiers would limit how much we can trust this quorum, but it would certainly still be an improvement over the status quo. As long as one committee member is honest, we should be able to bootstrap this image. SNARKs would provide much stronger guarantees, but the feasibility of these would depend on the complexity of the (open source) comparison and layout-versus-schematic (LVS) algorithms employed as SNARKs introduce high computational overhead. Fortunately, we only need to construct a few such proofs, after which the images for which the proofs were constructed can be used to cross check other chips.  A more efficient approach is to use TEEs to produce these proofs. Due to their currently limited security model, this would look something like the first idea of trusting a committee but with some additional security introduced. All of the approaches above are limited by the fab's appetite for their chips to be imaged in the first place. If a fab does not want GDS's to be public, they probably don't want images that provably resemble the GDS to be public. Design teams could be denied access to high quality process nodes if TSMC, Samsung and similar get wind of such proof generation. 
 
 The combination of the mathematical and pro-openness approaches is promising. The mathematical approaches serve as a good hedge against the open hardware movement taking a long time to get up to speed and helps to add additional assurances to partially open architectures like OpenTitan. One approach is technical while the other requires navigating patents and licensing or convincing large corporations to change their stance on something, presenting two very different forms of risk.