sskeirik

Problem: Fetching pages from the DB is too slow

Possible Solutions:

1. Make fetching a single page faster
2. Fetch multiple pages in parallel

Approach

First measure relative overhead of different parts of page fetching process to understand where time is being spent:

sskeirik

CI Workflow

Terminology

So, to ground our discussion about CI workflows, we'll need some terminology. To start, we have two repos with the following commit references:

Target Repo	Branch/Commit Ref	Data Source	Description
evm-semantics	master	evm-semantics git history	primary branch

sskeirik

The following seems to be a technique that lets us control the precise commit history that is generated when a PR is merged. The reason why this matters is that, if we follow this technique, it will simplify our merges in the future.

Git Development Workflow and Fast-Forward Merges

In my mind, in an ideal world, our commit graph would look something like this:

 * <- work-in-progress-feature
 |

sskeirik

perf Introduction

Using the perf tool centers around the following concepts:

1. events - these are hardware interrupts, hardware counters, or software events can be tracked
2. targets - while these CPUs, processes, or threads are executing, events will be tracked (tracking is disabled otherwise)
3. filters - these are predicates on event contexts used to control which events are tracked in which contexts

As I understand it, perf can operate in two main modes (as indicated by the perf stat and perf record subcommands):

sskeirik

Offsides: Blockchain Scaling and Interoperability

Blockchain Layers

Interoperability and scaling solutions for blockchains can be implemented at two different layers:

• Layer 1 (L1) - the code which implements the blockchain runtime (e.g., gossip, consensus, txn processing, etc.); L1 updates require a hard/soft network fork
• Layer 2 (L2) - any code which is not baked into the blockchain runtime (e.g., smart contracts, external entities); L2 updates do not require network forks

Let's use L1/L2 scaling/interoperability to to refer solutions implemented at the respective layer.

sskeirik

K Papers

Theory/Notation Papers

Year	Type	Name	URL
2003	Notes	CS322 Fall 2003: Programming Language Design - Lecture Notes –	https://www.ideals.illinois.edu/handle/2142/11385
2005	Tech Report	K: a Rewrite-based Framework for Modular Language Design, Semantics, Analysis and Implementation - Version 1 -	https://www.ideals.illinois.edu/handle/2142/11215
2006	Tech Report	K: a Rewrite-based Framework for Modular Language Design, Semantics, Analysis and Implementation - Version 2 -	https://www.ideals.illinois.edu/handle/2142/11284
2007	Tech Report	K: a Rewrite-based Framework for Modular Language Design, Semantics, Analysis and Implementation - Preliminary Version -	https://www.ideals.illinois.edu/handle/2142/11354

sskeirik

#!/bin/bash

if [ -z "$SANDBOX_PATH" ] || [ ! -f "$SANDBOX_PATH/sandbox" ] ; then
    echo "Error: \$SANDBOX_PATH must be defined and point to a sandbox binary."
    echo "To use this script, first clone the Algorand sandbox:"
    echo
    echo "git clone https://github.com/algorand/sandbox"
    echo
    echo "Then set \$SANDBOX_PATH to the newly created directory for the git clone"
    echo

sskeirik

rule <k> ADD => . ... </k>
     <stack> [ int I ] ; [ int J ] => [ int (I +Int J) ] ... </stack>

sskeirik

<k> ADD </k>
<stack> [ int 2 ] ; [ int 3 ] </stack>

sskeirik

// Symbolic Unit Test for Identity Function
// lines 3 and 24 represent our input and expected output stack respectively
input { Stack_elt nat $N } ;
code { DUP ;
       PUSH nat 0 ;
       SWAP ;
       INT ;
       GT ;
       // Loop assigned name @I
       LOOP @I {