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

GitHub PR Merges

Introduction

When a PR is opened on GitHub, there are three branches/commit references involved:

Branch/Commit Ref	Description
base	The branch into which changes will be merged
head	The PR branch which contains changes to be merged into base

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 {

sskeirik

input { Stack_elt nat 5 } ;
code { DUP ;
       PUSH nat 0 ;
       SWAP ;
       INT ;
       GT ;
       LOOP {
           PUSH nat 1 ;
           ADD ;
           DUP ;