Style takeaways

easy/src/2pc-takeaways.typ

@@ -1,19 +1,17 @@
 #import "preamble.typ":*
 
-= 2PC Takeaways
-
-#green[
-1. A _garbled circuit_ allows Alice and Bob to jointly compute some 
-  function over their respective secret inputs. We can think of this 
+#takeaway[2PC Takeaways][
+1. A _garbled circuit_ allows Alice and Bob to jointly compute some
+  function over their respective secret inputs. We can think of this
   as your prototypical _2PC_ (two-party computation).
-2. The main ingredient of a garbled circuit is _garbled gates_, 
-  which area gates whose functionality is hidden. This can be done 
-  by Alice precomputing different outputs of the garbled circuit 
+2. The main ingredient of a garbled circuit is _garbled gates_,
+  which area gates whose functionality is hidden. This can be done
+  by Alice precomputing different outputs of the garbled circuit
   based on all possible inputs of Bob, and then letting Bob pick one.
-3. Bob "picks an input" with the technique of _oblivious transfer (OT)_. 
-  This can be built in various ways, including with commutative 
+3. Bob "picks an input" with the technique of _oblivious transfer (OT)_.
+  This can be built in various ways, including with commutative
   encryption or public-key cryptography.
 4. More generally, it is also possible for a group of people to
-  compute whatever secret function they want, which is the field of 
+  compute whatever secret function they want, which is the field of
   _multiparty computation (MPC)_.
 ]

easy/src/fhe-takeaways.typ

@@ -1,11 +1,9 @@
 #import "preamble.typ":*
 
-= FHE Takeaways
-
-#green[
+#takeaway[FHE Takeaways][
 1. A _fully homomorphic encryption_ protocol allows Bob to compute some function $f(x)$ for Alice in a way that Bob doesn't get to know $x$ or $f(x)$.
 2. The hard problem backing known FHE protocols is the _learning with errors (LWE)_ problem, which comes down to deciding if a system of "approximate equations" over $F_q$ is consistent.
-3. The main idea of this approach to FHEs is to use "approximate eigenvalues" as the encrypted computation and an "approximate eigenvector" as the secret key. 
+3. The main idea of this approach to FHEs is to use "approximate eigenvalues" as the encrypted computation and an "approximate eigenvector" as the secret key.
   Intuitively, adding and multiplying two matrices with different approximate eigenvalues for the same eigenvector approximately adds and multiplies the eigenvalues, respectively.
 4. To carefully do this, we actually need to control the error blowup with the _flatten_ operation. This creates a _leveled FHE_ protocol.
 ]

easy/src/kzg-takeaways.typ

@@ -1,8 +1,6 @@
 #import "preamble.typ":*
 
-= KZG Takeaways
-
-#green[
+#takeaway[KZG Takeaways][
 1. _Elliptic curves_ are very useful in cryptography. Roughly speaking, they are sets of points (usually in $FF_p^2$) that satisfy some group law / "addition." The BN254 curve is a good "typical curve" to keep in mind.
 2. The _discrete logarithm_ assumption is a common "hard problem assumption" used in cryptography with different groups. Specifically, since elliptic curves are groups, discrete logarithm over elliptic curves is very often used.
 3. _Commitment schemes_ are ways for one party to commit values to another. Elliptic curves enable _Pedersen commitments_, a very useful example of a commitment scheme.

easy/src/preamble.typ

@@ -56,30 +56,33 @@
 
 #let todo = thmbox("todo", "TODO", fill: rgb("#ddaa77")).with(numbering: none)
 #let gray(body) = block(
-    fill: luma(210),
-    inset: 8pt,
-    radius: 4pt,
-    width: 100%,
-    [#body]
+  fill: rgb("#eeeeee"),
+  inset: 8pt,
+  radius: 4pt,
+  width: 100%,
+  [#body]
 )
 
 // set this flag to true if we are printing (in which case
-// we will see no blue text but will see subscriipt instead)
+// we will see no blue text but will see subscript instead)
 // and false if we are just doing a pdf
 #let print_flag = true
-#let green(body) = block(
-    fill: rgb("#aaeed9"),
-    inset: 8pt,
-    radius: 4pt,
-    width: 100%,
-    [#body]
+#let takeaway(title, body) = block(
+  fill: rgb("#eeeeee"),
+  inset: 8pt,
+  radius: 4pt,
+  breakable: false,
+  [
+    = #title
+    #body
+  ]
 )
 
 #let proof = thmproof("proof", "Proof")
 #let solution = thmproof("proof", "Solution")
 
-#let assumption = thmbox("main", "Assumption", fill: rgb("#eeeeaa"), base_level: 1)
-#let goal = thmbox("main", "Goal", fill: rgb("#eeeeaa"), base_level: 1)
+#let assumption = thmbox("main", "Assumption", fill: rgb("#ffffdd"), base_level: 1)
+#let goal = thmbox("main", "Goal", fill: rgb("#ffffdd"), base_level: 1)
 
 #let url(s) = {
   link(s, text(font:fonts.mono, s))

easy/src/snark-takeaways.typ

@@ -1,8 +1,6 @@
 #import "preamble.typ":*
 
-= SNARK Takeaways
-
-#green[
+#takeaway[SNARK Takeaways][
 1. A _SNARK_ can be used to succinctly prove that a piece of computation has been done correctly; specifically, it proves to some Verifier that the Prover had the K(nowledge) of some information that worked as feasible inputs to some computational circuit.
 2. The _arithmetization_ of the circuit is a way of converting circuits to arithmetic. Specifically for PLONK (but also other SNARKs, e.g. Groth16), our arithmetization is systems of quadratic equations over $FF_q$, meaning that what PLONK does under the hood is proving that a system of these equations are satisfied.
 3. The work under the hood of PLONK comes down to polynomial commitments (specifically KZG). KZG allows PLONK's gate checks and copy checks.