Introducing ICortex, our new Jupyter kernel that allows you to generate Python code from natural language prompts: {%youtube AtVCBNq48oc %} ICortex is a drop-in replacement for the IPython kernel that powers Jupyter Notebooks. It is open source, fully extensible, and can connect to multiple code generation services, including TextCortex API, OpenAI Codex API, locally-running HuggingFace models, and so on. Whether you are ...

Background Control Mechanisms for Trustless Self-Governing Protocols It is a feature of public blockchains, where a protocol parameter needs to adapt to certain conditions, but should not be controlled by a specific participant. The solution is to implement a mechanism where it auto-adjusts, according to quantifiable and objective conditions. The primary example is Bitcoin’s difficulty adjustment. There, variations in average block time are used to dynamically adjust Bitcoin’s block difficulty, every 2016 blocks. Owing to difficulty adjustment, Bitcoin blocks are mined every 10 minutes on average without any external control. Shifts in block time feed back into the difficulty parameter, which then dampens said shifts, creating a negative feedback loop. Here, Bitcoin's designer made use of elementary control theory, setting mean block time as a process variable and difficulty adjustment as the control action: Gas Price Volatility Blockchains have a limited supply, and a vertical supply curve. For that reason, blockchain resources are subjected to very high price volatilities, once user demand surpasses platform capacity. Let's consider Ethereum. Demand for gas isn’t distributed equally around the globe. Ethereum users exist in every inhabited continent, with the highest demand seen in East Asia, primarily China. Europe+Africa and the Americas seem to be on par in terms of demand. This results in predictable patterns that follow the peaks and troughs of human activity in each continent. The correlation between gas usage and price is immediately noticeable, demonstrated by a 5 day period from March 2019. The grid marks the beginnings of the days in UTC, and the points in the graph correspond to hourly averages, calculated as:

In Proof of Work We investigate the strategy where miners mine empty blocks to reduce the uncertainty of mining a block which is invalid because it contains a transaction that is already included by another block. In this case, the miner is aware of the new block, already has its hash and/or header, but has not downloaded the rest of the block which contains the transactions. Constant reward per mined block: $R$ Time required to mine an empty block: $T_e$ Time required to mine a full block: $T_f$ Gas price: $P$ Gas in a block: $G$ Block gas limit: $G_\max$ Average tx fee collected from a block: $F(G) = PG$

Users need to specify a fee when submitting their transactions. When it is a validator’s turn to propose a block, the validator collects transactions from the transaction pool, executes them in a certain order, and publishes them in a new block. Fees in a block are distributed to all validators pro rata. This is to weaken the incentive to steal transactions from other blocks, in case the block proposer receives the whole fee. The protocol has the following parameters: $P$: Average gas price of the previous era. This value is updated at the end of each era, calculated by dividing total collected fees by total consumed gas. $G$: Gas in a block. $G_{\text{max}}$: Block gas limit. $G \leq G_{\text{max}}$ for every block. $F$: Total fee collected from transactions in a block. $N$ is the current number of validators, $w_i$ is the normalized weight of validator $i$.

Disclaimer: This is work in progress. Smart contract platforms like Ethereum have network parameters that dictate how often a block is to be produced, and how much computation can be performed in a block or how big a block's size can be. The selection of these parameters determine the maximum amount of computation per second that the overall network can perform. We want to maximize that number by choosing the right parameters. Protocol execution consists of cycles called rounds. Each round has a leader (validator), responsible for proposing a block at the beginning of that round. We mean by block time, denoted by $\Delta$, the length of a round. Block time is spent by first executing transactions and including them in a new block, and then by propagating that block throughout the network. Ideally, a leader should have enough time to receive and verify his predecessor's block before the previous round ends, so that he can declare it as a parent of his block when his round begins. If that is not the case, then the blockchain would fork. To prevent validators from creating arbitrarily large blocks or blocks with arbitrarily many operations, certain limits are imposed on blocks at the protocol level. These protocol parameters are: Block time: Defined above. Block size limit: Maximum size of a block in bytes.

While memory usage of a program on a distributed network can be objectively quantified, its runtime depends on the hardware configuration of each computer. Our end goal is to standardize metering of runtime for all machines in the network. For that reason, we will use models that predict runtimes on an "average network node". The context of this research is metering resource usage in smart contract platforms. A transaction on such a platform generally consist of repetitions of opcodes to be executed by the underlying VM, or calls to functions that are implemented externally, but can be called within the VM. Their runtimes differ from call to call and from machine to machine---however, by fitting predictive models in a testing environment that represents an average network node, we can determine how much time these operations should take. Using these models, everyone can agree on a single runtime, despite measuring different values individually. Moreover, we realize that we have a general computer science problem at hand, where there is a need to predict the runtime of a program with a certain degree of confidence. For that reason, we keep our nomenclature abstract, and consider programs consisting of certain operations, defined as:

A Proof of Stake system encapsulates an market where validators participate in block proposal and voting, in order to receive rewards. Just like a regular marketplace, the protocol needs to be designed in such a way that validators are incentivized to behave honestly, as much as possible. A concept central to such a design is risk sharing: ALL (LITERALLY) IN THE SAME BOAT Greek is a language of precision; it has a word describing the opposite of risk transfer: risk sharing. Synkyndineo means “taking risks together,” which was a requirement in maritime transactions. The Acts of the Apostles describes a voyage of St. Paul on a cargo ship from Sidon to Crete to Malta. As they hit a storm: “When they had eaten what they wanted they lightened the ship by throwing the corn overboard into the sea.” Now while they jettisoned particular goods, all owners were to be proportioned the costs of the lost merchandise, not just the specific owners of the lost merchandise. For it turned out that they were following a practice that dates to at least 800 B.C., codified in Lex Rhodia, Rhodian Law, after the mercantile Aegean island of Rhodes; the code is no longer extant but has been cited since antiquity. It stipulates that the risks and costs for contingencies are to be incurred equally, with no concern for responsibility. Justinian’s code summarizes it:

(This formulation is a next iteration following a previous article) Let us assume that each validator has staked some number of tokens, which determines how much reward they will receive. Let $w_i$ be the normalized weight of validator $i$. Validators have to have nonzero weights. Each validator is supposed to send exactly one message, and the strategies are SEND and DON'T SEND respectively. Let $x=(x_1,\dots,x_N)$ be the tuple of boolean values that hold whether a validator has sent a message. Then participating weight is calculated as $$ W_p(x) = \sum_{i\in V}x_iw_i $$

The round exponent adjustment strategy is currently defined in the Highway paper as: There will likely be a nominal round exponent for the whole network, below which finalization of most blocks would fail. We end up with a repeating cycle which looks like: acceleration failure of more than $C_0$ out of $C_1$ rounds deceleration wait for the next acceleration goto 1

# How to price operations in smart contracts ## Time-based pricing Blocks are proposed (or mined) sequantially. The protocol enforces a round length $T$ in which all the operations must be completed before the next block can be proposed. This includes the time required to execute the transactions, as well the time required to propagate the block. In that sense, we impose no distinction between a computational operation such as addition or multiplication, and the propagation of a payload bit to

# Rate of return and yield during a release schedule According to the quantity theory of money, when new tokens are issued, the price of the token should decrease accordingly. We assume an inflation rate $J$ and also expect the market cap to grow with a rate $G$[^1]. Then the price at the end of the first year is equal to $$ P(J, G) = P_0\left(\frac{1+G}{1+J}\right) $$ where $P_0$ is the initial price. We measure measure rate of return and yield by comparing the dollar values of a validato

# Delegation and Centralization Decentralization is a desired property of blockchain networks. It implies more economic freedom for those who are are running it, those who want to join it, and those who are using it. Moreover, it makes them much harder to kill---think about Bittorrent. We tend to favor systems that are more likely to survive. De/centralization has been explored thoroughly in [an article by Vitalik](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274)

# [DEPRECATED] Era Scores for Highway Reward Distribution This proposal is deprecated. Refer to https://hackmd.io/@onur/SJItG9I6B instead. ## Idea Our idea: - You get 1 point for every one of your rounds (according to your round parameter, but even if you weren't the leader) whose block was finalized within that round, and where you fully participated (with lambda response and omega message). - E.g. assume Alice is the leader, makes a block, and indicates that her rounds are 2 seconds. She a

# Gas reservation I was trying to come up with a practical solution of making sure validators keep their end of the deal and execute transactions submitted with reserved gas. The problem is the lack of law enforcement, so we can't physically enforce validators to do that. We can otherwise cryptographically verify whether a transaction has been sent from a user. So the only thing we need to do is get the validators to deposit some tokens, and make it so that honoring the agreement is a dominant