chore: nits and formating

rakita · Jul 9, 2023 · bb0eceb · bb0eceb
1 parent a40108f
commit bb0eceb
Show file tree

Hide file tree

Showing 4 changed files with 11 additions and 14 deletions.
diff --git a/content/blog/parallel_evm_claim/index.md b/content/blog/parallel_evm_claim/index.md
@@ -28,10 +28,10 @@ All examples start from the point that we received a DAG of transaction and the
 
 We have two transactions that read/write to the **same** state (there is only one state that all of them share) and the update to that state is atomic. The example here is very simple but it allows us to set up some groundwork and initial ideas of what is checked.
 
-[Mermaid graph](https://mermaid.live/edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp)
-
 ![](./example_2tx.png)
 
+[Graph](https://mermaid.live/edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp)
+
 
 For the sake of explaining we are simplifying state and seeing it as a list of accounts, these "accounts" can be a balance/nonce/code hash(code)/storage slot, it is just easier to reason and think about in simpler form.
 
@@ -50,7 +50,6 @@ The second example is having a third transaction that depends on the first one.
 
 ![](./example_chain.png)
 
-
 [Graph](https://mermaid.live/edit#pako:eNpdjjEOwjAMRa8SeUTNQMuUgYmViZEwWI0LkZoEpU4Fqnp3DC1CwtPX-7b1JmiTIzAwMDIdPF4zBj3WNiqZ8-aitN4rfmwXIGEFzRc0K9j9n9RQQaAc0Dv5P71rC3yjQBaMREcdlp4t2DjLKhZOp2dswXAuVEG5u58RmA77QSg5zykfF-eP-vwC_v88KA)
 
 This is the first example of dependent transactions and`tx3` can access only accounts that are in the original state or touched by `tx1`, if both `tx3` and `tx2` access the same account this would make the parallelism claim invalid.
@@ -63,7 +62,6 @@ Modelling dependency can be tricky but in parallel execution, there are only two
 
 ![](./example_fork_join.png)
 
-
 [Graph](https://mermaid.live/edit#pako:eNpdj7EOwjAMRH-l8oiagRSWDEysTIwNg9W4EKlJUOogUNV_J9BWFXg6vTtZdwM0wRAo6BmZjhavEZ14SO2LfPXmUghxKPi5nUAWM6gWUM1g95_YL0D-gvWphBIcRYfW5AbDx9bAN3KkQWVpqMXUsQbtxxzFxOH88g0ojolKSHezdgbVYtdnSsZyiKdp1Xfc-AaEXkTp)
 
 There is one fork here, and can be seen in the example of `tx1` that forks its state to chains of `tx5` and `tx3`. This means that there is a dependency between `tx5` and `tx1`, `tx3` and `tx1` but there are no dependencies on `tx3` and `tx5` and they can be run in parallel.
@@ -75,14 +73,13 @@ The mechanism of marking the state works the same as in the first example. `tx5`
 
 This is a good example that tests our initial mechanism of marking of accessed state.
 
-[Graph](https://mermaid.live/edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg)
-
 ![](./example_diamont.png)
 
+[Graph](https://mermaid.live/edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg)
 
 All previous statements should be valid here.
 
-For example `tx7` can only touch original state or `tx1`,`tx2`,`tx3`,`tx4`,`tx5` but not `tx6`, and same with `tx6` it can't touch state of `tx7`
+For example `tx7` can only touch original state or `tx1`, `tx2`, `tx3`, `tx4`, `tx5` but not `tx6`, and same with `tx6` it can't touch state of `tx7`
 
 ## How to check marks
 

diff --git a/public/atom.xml b/public/atom.xml
@@ -25,8 +25,8 @@
 &lt;p&gt;All examples start from the point that we received a DAG of transaction and the builder claims that transaction can be done in parallel. We want to execute those transactions in parallel and be sure that the claim is correct and that there are no inconsistencies (data races) that can happen.&lt;&#x2F;p&gt;
 &lt;h3 id=&quot;example-1-simple-two-parallel-transactions&quot;&gt;Example 1: simple two parallel transactions&lt;&#x2F;h3&gt;
 &lt;p&gt;We have two transactions that read&#x2F;write to the &lt;strong&gt;same&lt;&#x2F;strong&gt; state (there is only one state that all of them share) and the update to that state is atomic. The example here is very simple but it allows us to set up some groundwork and initial ideas of what is checked.&lt;&#x2F;p&gt;
-&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;mermaid.live&#x2F;edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp&quot;&gt;Mermaid graph&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
 &lt;p&gt;&lt;img src=&quot;https:&#x2F;&#x2F;rakita.github.io&#x2F;blog&#x2F;blog&#x2F;parallel-evm-claim&#x2F;.&#x2F;example_2tx.png&quot; alt=&quot;&quot; &#x2F;&gt;&lt;&#x2F;p&gt;
+&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;mermaid.live&#x2F;edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp&quot;&gt;Graph&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
 &lt;p&gt;For the sake of explaining we are simplifying state and seeing it as a list of accounts, these &amp;quot;accounts&amp;quot; can be a balance&#x2F;nonce&#x2F;code hash(code)&#x2F;storage slot, it is just easier to reason and think about in simpler form.&lt;&#x2F;p&gt;
 &lt;p&gt;Additionally, we should consider both reads and writes of accounts as the same thing. This can be explored as a follow-up but for the first iteration, it is easier to omit this distinction. So this means that the transaction touched state consists of both reads and writes that this transaction did. And with this, having an account read from two different parallel transactions is considered invalid.&lt;&#x2F;p&gt;
 &lt;p&gt;Now, the idea here is that on every access of an account (read or write) to mark that account in the state as accessed by that transaction. This means that if account &lt;code&gt;0x01&lt;&#x2F;code&gt; is accessed by &lt;code&gt;tx1&lt;&#x2F;code&gt; it will be marked as such and if &lt;code&gt;tx2&lt;&#x2F;code&gt; tries to access account &lt;code&gt;0x1&lt;&#x2F;code&gt; we will notice that account is already marked and see that there is inconsistency and data race in place.&lt;&#x2F;p&gt;
@@ -46,10 +46,10 @@
 &lt;p&gt;The mechanism of marking the state works the same as in the first example. &lt;code&gt;tx5&lt;&#x2F;code&gt; can now access the account of the original or &lt;code&gt;tx1&lt;&#x2F;code&gt; or &lt;code&gt;tx2&lt;&#x2F;code&gt; accounts if it accessed the state of &lt;code&gt;tx3&lt;&#x2F;code&gt; or &lt;code&gt;tx3&lt;&#x2F;code&gt; this would make parallel claim invalid.&lt;&#x2F;p&gt;
 &lt;h2 id=&quot;example-4-diamond-pattern&quot;&gt;Example 4: Diamond pattern&lt;&#x2F;h2&gt;
 &lt;p&gt;This is a good example that tests our initial mechanism of marking of accessed state.&lt;&#x2F;p&gt;
-&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;mermaid.live&#x2F;edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg&quot;&gt;Graph&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
 &lt;p&gt;&lt;img src=&quot;https:&#x2F;&#x2F;rakita.github.io&#x2F;blog&#x2F;blog&#x2F;parallel-evm-claim&#x2F;.&#x2F;example_diamont.png&quot; alt=&quot;&quot; &#x2F;&gt;&lt;&#x2F;p&gt;
+&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;mermaid.live&#x2F;edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg&quot;&gt;Graph&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
 &lt;p&gt;All previous statements should be valid here.&lt;&#x2F;p&gt;
-&lt;p&gt;For example &lt;code&gt;tx7&lt;&#x2F;code&gt; can only touch original state or &lt;code&gt;tx1&lt;&#x2F;code&gt;,&lt;code&gt;tx2&lt;&#x2F;code&gt;,&lt;code&gt;tx3&lt;&#x2F;code&gt;,&lt;code&gt;tx4&lt;&#x2F;code&gt;,&lt;code&gt;tx5&lt;&#x2F;code&gt; but not &lt;code&gt;tx6&lt;&#x2F;code&gt;, and same with &lt;code&gt;tx6&lt;&#x2F;code&gt; it can&#x27;t touch state of &lt;code&gt;tx7&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
+&lt;p&gt;For example &lt;code&gt;tx7&lt;&#x2F;code&gt; can only touch original state or &lt;code&gt;tx1&lt;&#x2F;code&gt;, &lt;code&gt;tx2&lt;&#x2F;code&gt;, &lt;code&gt;tx3&lt;&#x2F;code&gt;, &lt;code&gt;tx4&lt;&#x2F;code&gt;, &lt;code&gt;tx5&lt;&#x2F;code&gt; but not &lt;code&gt;tx6&lt;&#x2F;code&gt;, and same with &lt;code&gt;tx6&lt;&#x2F;code&gt; it can&#x27;t touch state of &lt;code&gt;tx7&lt;&#x2F;code&gt;&lt;&#x2F;p&gt;
 &lt;h2 id=&quot;how-to-check-marks&quot;&gt;How to check marks&lt;&#x2F;h2&gt;
 &lt;p&gt;Every transaction could have a list of previous dependent transactions, and when checking the mark inside the database we compare it if it is found inside that list.&lt;&#x2F;p&gt;
 &lt;p&gt;This list can be sorted so finding particular values can be done by binary search. The list size depends on the number of dependent transactions.&lt;&#x2F;p&gt;

diff --git a/public/blog/parallel-evm-claim/index.html b/public/blog/parallel-evm-claim/index.html
@@ -250,8 +250,8 @@ <h1 id="algorith-explained">Algorith explained</h1>
 <p>All examples start from the point that we received a DAG of transaction and the builder claims that transaction can be done in parallel. We want to execute those transactions in parallel and be sure that the claim is correct and that there are no inconsistencies (data races) that can happen.</p>
 <h3 id="example-1-simple-two-parallel-transactions">Example 1: simple two parallel transactions</h3>
 <p>We have two transactions that read/write to the <strong>same</strong> state (there is only one state that all of them share) and the update to that state is atomic. The example here is very simple but it allows us to set up some groundwork and initial ideas of what is checked.</p>
-<p><a href="https://mermaid.live/edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp">Mermaid graph</a></p>
 <p><img src="https://rakita.github.io/blog/blog/parallel-evm-claim/./example_2tx.png" alt="" /></p>
+<p><a href="https://mermaid.live/edit#pako:eNpdTrsOwjAQ-5XII2oGOmZgYmViJAyn5gqRmgSlFwSq-u8cMCDhyfJD9oKhBIbDLCS8j3SplOy999koTpuzsXZn5LH9F3p0SFwTxaDt5W17yJUTezilgUdqk3j4vGqUmpTjMw9wUht3aLfw24MbaZpV5RCl1MP30efY-gKkKDNp">Graph</a></p>
 <p>For the sake of explaining we are simplifying state and seeing it as a list of accounts, these &quot;accounts&quot; can be a balance/nonce/code hash(code)/storage slot, it is just easier to reason and think about in simpler form.</p>
 <p>Additionally, we should consider both reads and writes of accounts as the same thing. This can be explored as a follow-up but for the first iteration, it is easier to omit this distinction. So this means that the transaction touched state consists of both reads and writes that this transaction did. And with this, having an account read from two different parallel transactions is considered invalid.</p>
 <p>Now, the idea here is that on every access of an account (read or write) to mark that account in the state as accessed by that transaction. This means that if account <code>0x01</code> is accessed by <code>tx1</code> it will be marked as such and if <code>tx2</code> tries to access account <code>0x1</code> we will notice that account is already marked and see that there is inconsistency and data race in place.</p>
@@ -271,10 +271,10 @@ <h2 id="example-3-chain-forks-and-joins">Example 3: Chain forks and joins</h2>
 <p>The mechanism of marking the state works the same as in the first example. <code>tx5</code> can now access the account of the original or <code>tx1</code> or <code>tx2</code> accounts if it accessed the state of <code>tx3</code> or <code>tx3</code> this would make parallel claim invalid.</p>
 <h2 id="example-4-diamond-pattern">Example 4: Diamond pattern</h2>
 <p>This is a good example that tests our initial mechanism of marking of accessed state.</p>
-<p><a href="https://mermaid.live/edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg">Graph</a></p>
 <p><img src="https://rakita.github.io/blog/blog/parallel-evm-claim/./example_diamont.png" alt="" /></p>
+<p><a href="https://mermaid.live/edit#pako:eNpd0D0PgjAQBuC_Qm40MMiHJB2cXJ0crcOFHkpCKSlXoyH8d6uUmPSmy3PvcHczNEYRCJgYmU4d3i3q7JnLIfF13d2SLDsm_Nqv4JsAxQZFgDJOVBvkMZQBDhtUAeo4Ucd75JCCJquxU37p-TuWwA_SJEH4VlGLrmcJclh8FB2by3toQLB1lIIb1f9MEC32k1dSHRt7Xh_x-8fyAQIhUhg">Graph</a></p>
 <p>All previous statements should be valid here.</p>
-<p>For example <code>tx7</code> can only touch original state or <code>tx1</code>,<code>tx2</code>,<code>tx3</code>,<code>tx4</code>,<code>tx5</code> but not <code>tx6</code>, and same with <code>tx6</code> it can't touch state of <code>tx7</code></p>
+<p>For example <code>tx7</code> can only touch original state or <code>tx1</code>, <code>tx2</code>, <code>tx3</code>, <code>tx4</code>, <code>tx5</code> but not <code>tx6</code>, and same with <code>tx6</code> it can't touch state of <code>tx7</code></p>
 <h2 id="how-to-check-marks">How to check marks</h2>
 <p>Every transaction could have a list of previous dependent transactions, and when checking the mark inside the database we compare it if it is found inside that list.</p>
 <p>This list can be sorted so finding particular values can be done by binary search. The list size depends on the number of dependent transactions.</p>

diff --git a/public/search_index.en.js b/public/search_index.en.js