Deor


ethers has 3 main sign methods:

- `wallet.signMessage`
  - this hashes the given message, then signs it
- `wallat.signTransaction`
  - serializes, hashes, then signs it
- `wallet._signTypedData`
  - eip-712 hashes it, then signs it

but, if you have your own already hashed message you want to sign, you cant use either of these three.

you can, instead:

```ts
import { joinSignature, keccak256 } from 'ethers/lib/utils';

// assuming you already have a wallet instantiated
const signature = joinSignature(
  wallet._signingKey().signDigest(ethers.utils.arrayify(msgHash))
);
```


how to sign an already hashed message with ethers, when you cant use wallet.signMessage, wallet.signTransaction, or wallet._signTypedData

how to sign an already hashed message with ethers

A thread about people leaving money on the table by not claiming their bridges on Ethereum.

Sweeping unclaimed bridges on Ethereum


```tsx
error /Users/deor/Desktop/Code/deor-blog-v2/node_modules/puppeteer: Command failed.
Exit code: 1
Command: node install.js
Arguments:
Directory: /Users/deor/Desktop/Code/deor-blog-v2/node_modules/puppeteer
Output:
The chromium binary is not available for arm64.
```

I already have chromium downloaded, but if not:

```tsx
brew install chromium --no-quarantine
```

Add this to `~/.zshrc` or to your shell profile (`.bashrc`, `.bash_profile`, etc):

```tsx
export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
export PUPPETEER_EXECUTABLE_PATH=`which chromium`
```

Reload the terminal:

```
source ~/.zshrc
// or .bashrc, .bash_profile, etc
```


Fix for: “The chromium binary is not available for arm64."

fix for: “The chromium binary is not available for arm64.”


```tsx
Parsing error: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead.
```

How to fix:

- Update `@typescript-eslint/eslint-plugin` & `@typescript-eslint/parser` to latest versions.
- Restart your eslint server, for vscode, hit `ctrl + shift + p` => `Restart ESLint Server`


Fix for "originalKeywordKind" has been deprecated since v5.0.0 and can no longer be used

A chrome extension that does not allow you to open up multiple tabs of twitter.

single-twitter-tab


To pull a docker container from a private registry, create a docker-registry secret via:

```bash
kubectl create secret docker-registry regcred --docker-server=https://index.docker.io/v1/ --docker-username=xxx --docker-password=xxx --docker-email=xxx
```

Make sure to replace the username / password / email with your information. Also, replace the docker server url if using a registry different from docker hub.

Common registry server urls are (saving these for later, because sometimes these are annoying to find)

- Docker hub: `https://index.docker.io/v1/`
- Github Actions: `docker.pkg.github.com/[owner]/[repo]`
- Quay: `quay.io`
- Google Container Registry: `gcr.io` (global endpoint, might need to use a regional one)
- Amazon Elastic Container Registry: `[aws_account_id].dkr.ecr.[region].amazonaws.com`
- Azure Container Registry: `[registry_name].azurecr.io`

Example using the secret in deployment config:

```bash
apiVersion: apps/v1
kind: Deployment
metadata:
    name: whoami
spec:
    replicas: 1
    selector:
        matchLabels:
            app: whoami
    template:
        metadata:
            labels:
                app: whoami
        spec:
            containers:
                - name: whoami-container
                  image: d3or/whoami
                  ports:
                      - containerPort: 3000
            imagePullSecrets:
                - name: regcred
```


How to pull a docker container from a private registry in Kubernetes

Pulling Docker Container from Private Registry in Kubernetes

EIP-5 proposed that gas is only charged for memory that is actually written to at the time CALL returns, instead of all of the memory reserved.

Ethereum History: Gas cost changes for memory usage

Homestead was the second major version of the Ethereum network. It was released on March 14, 2016. Homestead was a planned hard fork of the Ethereum network and included several protocol changes.

Ethereum History: Gas exploit before Homestead

"gasless" ERC20 transfers, known as permits in ERC-2612, may actually cost more gas than regular transfers.

The True Cost of 'Gasless' ERC20 Transfers


The swagger openapi v3.0.3 json that the [Fastify Swagger plugin](https://github.com/fastify/fastify-swagger) generates includes an empty schema object field when there are no schemas present. The [openai-trypescript tool](https://github.com/drwpow/openapi-typescript) has issues dealing with this empty object when trying to generate typescript types programatically.

```tsx
swagger.d.ts
.
.
.
export interface components {
  schemas: {
  }; -- wrong type, this means "any non-nullish value". It should be schemas: never
  responses: never;
  parameters: never;
  requestBodies: never;
  headers: never;
  pathItems: never;
}
.
.
.
```

Two work arounds:

- Delete the empty component.schema object from the swagger file before generating the types.
- Upgrade openapi-typescript version to `next` where this bug is fixed. At time of writing the version where this is fixed is not released yet. The current latest published version is `6.7.5` , the next version where this is fixed should be ~ `7.0.0` .


fix for openapi-typescript issue with empty components.schema object

Fix for openapi-typescript issue with empty swagger spec components.schema object


This started happening with a typescript project after updating typescript version and ts-node version:

```jsx

yarn start
yarn run v1.22.18
warning package.json: No license field
$ yarn migrate up && node dist/src/index.js
warning package.json: No license field
$ node ./node_modules/node-pg-migrate/bin/node-pg-migrate -d POSTGRES_URL -m ./src/migrations --no-check-order up
/project/node_modules/cliui/build/index.cjs:291
const stringWidth = require('string-width');
                    ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /project/node_modules/string-width/index.js from /project/node_modules/cliui/build/index.cjs not supported.
Instead change the require of index.js in /project/node_modules/cliui/build/index.cjs to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/project/node_modules/cliui/build/index.cjs:291:21)
    at Object.<anonymous> (/project/node_modules/yargs/build/index.cjs:1:58136)
    at Object.<anonymous> (/project/node_modules/yargs/index.cjs:5:30)
    at Object.<anonymous> (/project/node_modules/node-pg-migrate/bin/node-pg-migrate:9:15) {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v18.18.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```

Fix: Delete amy mention of string-width from yarn.lock and run yarn again. Or, if you do not care about your `yarn.lock`, delete the file and run `yarn` again.


Fix for Error [ERR_REQUIRE_ESM]: require() of ES Module string-width

fix: Error [ERR_REQUIRE_ESM]: require() of ES Module string-width


Locally running services on k8s (or [k3s](https://k3s.io/), in my case) can be annoying to expose publically nowadays because ISPs usually provision dynamic rotating IPs instead of static ones. Personally, my ISP said they could provision me a static IP for a monthly cost, which I was planning to do until I remembered services like ngrok exist.

While ngrok is cool, something open source / more controllable would be nicer for a homelab. This was a problem I ran into several months ago, and I never ended up solving it because it was too much work at the time.

While scrolling twitter I ran into this cool startup that makes varying open source software, called [Fyra Labs](https://github.com/FyraLabs). They actually made [Chisel Operator](https://chisel.fyralabs.com/) ([github here,](https://github.com/fyralabs/chisel-operator) star it!), a kubernetes load balancer controller to easily allocate IPs and create load balancer services that can be accessed externally, via [chisel tunnels.](https://github.com/jpillora/chisel)

Setting it up was very easy, I did run into one issue due to [traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) and Chisel Operator both using servicelb. For now, because the cluster was fresh I re-installed k3s on my nodes with the `--disable traefik` flag. I later found out that I could have just disabled servicelb for traefik and it would have worked.

The setup process only took a couple steps:

1. Installing the chisel operator.
2. Choosing an external host for an `ExitNode` , which is where the chisel server will be running and where clients will access from. You can chose a provider like DigitalOcean, AWS, Linode, or you can self host a chisel server instance anywhere you want. I chose DigitalOcean because I had an account and wanted easy setup. If you are using a provider, you need to setup an `ExitNodeProvisioner` which automatically creates the server instances.
3. Creating the `LoadBalancer` service to expose the deployment via the setup exit node.

Brief (more detailed) tutorial for how to do the above:

### Installing the chisel operator

```jsx
kubectl apply -k https://github.com/FyraLabs/chisel-operator
```

Thats it..

### Setting up an `ExitNodeProvisioner`

I used DigitalOcean, but you can use AWS/DigitalOcean/Linode. Or you can learn how to self host your own ExitNode [here](https://chisel.fyralabs.com/guides/self-host-exit-node/).

For DigitalOcean, go to the API sections of your dashboard and make a read/write api key for the provisioner to use to automatically create droplets.

```yaml
apiVersion: chisel-operator.io/v1
kind: ExitNodeProvisioner
metadata:
  name: digitalocean-provisioner
  namespace: default
spec:
  DigitalOcean:
    auth: digitalocean-auth
    region: nyc1
---
apiVersion: v1
kind: Secret
metadata:
  name: digitalocean-auth
  namespace: default
type: Opaque
stringData:
  DIGITALOCEAN_TOKEN: 'YOUR_TOKEN_HERE'
```

### Creating the LoadBalancer service to expose a deployment

This is how you can expose a simple `whoami` deployment via an exit node the operator automatically provisioned on digital ocean. After applying this, look at the digital ocean dashboard and you can find the droplet that was provisioned there, and access the public IP.

```jsx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: containous/whoami
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  annotations:
    chisel-operator.io/exit-node-provisioner: "digitalocean-provisioner"
spec:
  selector:
    app: whoami
  ports:
    - port: 80
      targetPort: 80
  type: LoadBalancer
```

And thats it! Shoutout to [korewaChino](https://github.com/korewaChino) from Fyra Labs for creating the operator, and helping quickly merge a [PR for bumping the ubuntu version for the digital ocean droplet!](https://github.com/FyraLabs/chisel-operator/pull/21)


Consider that for a moment: everything we see around us is assumed to have had a cause and is contingent upon.

expose a local k3s server, without exposing your internet


You can use the `pong` websocket behavior to maintain a connection status when using [uWebSockets.js](https://github.com/uNetworking/uWebSockets.js), instead of just assuming a user is still connected between `open` & `close`. uWebSockets.js pings the client every 90 seconds by default, and by listening to the `pong` event, you can hook into the pong response from the client to keep track of the connection status.

```typescript
public socketServer: uWebSockets.TemplatedApp = uWebSockets.App();

.
.
.

const behavior: WebSocketBehavior<UserData> = {
  upgrade: async (res, req, context) => {
    try {
      let aborted = false;
      res.onAborted(() => {
        aborted = true;
      });

      if (aborted) {
        return;
      }

      res.upgrade(
        // Any user data here you want to assign to the websocket, like api key, id, etc
        { id: Math.random().toString(36).substring(2) },
        req.getHeader('sec-websocket-key'),
        req.getHeader('sec-websocket-protocol'),
        req.getHeader('sec-websocket-extensions'),
        context
      );
    } catch (err) {
      // This only happens if the user disconnects DURING the upgrade operation
    }
  },
  open: (ws) => this.newConnection(ws),
  message: (ws, message) => this.messageEvent(ws, message),
  close: (ws) => this.closeEvent(ws),
  pong: (ws) => {
    // Do any logic here you want to let your stack know a user is stil connected
    this.updateConnection(ws.id);
  },
};
this.socketServer.ws<UserData>('/*', behavior);
this.socketServer.listen('0.0.0.0', 3000);
```


Use the pong behavior to maintain a connection status when using uWebSockets.js

uWebSockets.js Pong Behavior for maintaining connection status

castle

module acquired by reservoir

SBF_FTX deleting tweets and tweeting to offset his total tweets count

nft-anomaly-detector

nft-sniper

Module Edge - Faster NFT Images

FullTx - An easier way to index Ethereum

Ingress Fanout for Kubernetes

ingress-fanout-tutorial


NFTs solved the problem of ownership. But they didn't solve the problem of metadata. Metadata is commonly stored on either a centralized server, or a peer-to-peer network like IPFS. Although this is a step in the right direction, it still leaves the metadata vulnerable to censorship.

I think that the best NFTs are the NFTs where there metadata are frozen inside the contract. Like SVG NFTs, or NFTs that are just a single number. But what about NFTs that have a lot of metadata?

How can we solve this? Contracts have size limits, how can we store images, which are thousands of bytes, in a smart contract for a 10k image NFT collection?

Possible solutions:

- On-chain image compression
- Proxy contracts that store the metadata on-chain, so we can avoid the size limit


NFT Metadata Alternatives

Fastify Redis Cache Plugin


# hardhat-gas-trackooor

[![npm version](https://badge.fury.io/js/hardhat-gas-trackooor.svg)](https://badge.fury.io/js/hardhat-gas-trackooor)


fastify-redis-cache

Fastify vs Express

sic-xe-assembler.js


## Introduction

SIC-XE stands for Simplified Instructional Computer Extra Equipment, and is a
hypothetical computer system. It is commonly used for instructional use and teaching, and is
primarily used and talked about in the textbook, System Software: An Introduction to Systems
Programming, by Leland Beck. For this project, I have been tasked with writing an assembler
implementation that can translate SIX-XE assembly listing into a solution file that includes
assembly listing accompanied with location counters and object code, as well as output an
object program that can be hypothetically loaded onto a SIC/XE machine.

For my implementation, I chose to write it in NodeJS. NodeJS is a JavaScript runtime
built on Chrome's V8 JavaScript engine that can run outside of the traditional browser. The
biggest reason behind choosing javascript was the ease of manipulating data structures
compared to its lower level language counterparts. Initializing, accessing, updating, and deleting
data structures in javascript can be done very simply, without the hassle of worrying about
memory leaks and more. By implementing the assembler in a higher level language, the focus
can instead be on the design of the assembler instead of the nuances of the chosen language.

## Implementation Overview

The assembler has three different phases to it: Pre-Processing,Pass 1, Pass 2, and
Post-Processing. The Pre-Processing phase takes input from a text file, and prepares it for the
assembler for Pass 1. Pass 1 builds the symbol table data, program blocks table, assigns
locations to each applicable line, and expands macros. Pass 2 takes the output from Pass 1,
and goes line by line generating object code and the related object program code, such as the
text records and modification records. The last phase is the Post-Processing phase, which
finalizes the object program, generates the text records and modification records, and then
writes the solution and object program files to the output directory.

## Pre-Processing

The Pre-Processing phase is very short and is simple. Its main goal is to separate the
tab delimited and new line separated assembly listing into an array which the assembler can
parse through. For this, I created a simple file management system which the assembler can
use for reading files and writing (Post-Processing also uses this). The assembler is passed a file
path, and the assembler calls the file parser with the path, which reads the file and immediately
separates it by new lines. This array of new lines is now iterated over, with every line being split
by a tab. The result is put into a line object which represents one singular line, and then it is
pushed onto an array of lines. The line object includes the line number, symbol, operation,
operand, and comment.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961691441070120/pasted_image_0.png'
  }
  alt="Image alt"

style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',
width: '50%',

    }}

/>

This array is now returned to the assembler for it to begin Pass 1.

## Pass 1

After Pre-Processing is completed, the assemblerbegins Pass 1. The main objective of
Pass 1 is to:

- Create a symbol table
- Create a program blocks table
- Recognize different control sections
- Handle literals & literal pools
- Expand macros

Pass 1 begins by initializing the necessary data structures. These are the symbol table object,
program blocks array of objects, literal array (LITTAB), and namTab, defTab, and argTab for
macro related operations. An important design decision I had was with the symbol table, and the
way it is organized as an object. Consider the following diagram showcasing the structure:

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961691143286866/pasted_image_0_1.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

The symbol table object is organized in a key-value pair manner. We can nest objects within the
symbol table objects, which is what is being done to handle the logic for various control
sections. The reason for this is so that symbols from other control sections can not overwrite
symbols from other control sections. It also helps in Pass 2 when accessing the correct symbol,
which we will talk more about later on.

To access a symbol, the following syntax must be used:

`SymbolTable[current control section][symbol name]`

This will result in an object that looks like:
`{ address : “000A”, block: 0 }`

The other data structures used are simpler. The program blocks array contains a list of objects.
Each object includes the block name, block number, block length, and starting address. The
literal array stores lines which are literals, and follow the same object scheme as the line
mentioned previously.

For macro related operations, we have three data structures. defTab is where the macro
definition is stored, and is accessed via `defTab[macroname]`. It is an array of lines that make up the macro definition. The namTab stores the location counter of where the macro is first defined,
in the form `namTab[macroname]`. The argTab stores the arguments to pass to the macro, in an
array where each element is an argument. The format is `argTab[macroname]`.

After data structure initialization, the assembler now moves on to make its first pass over the
array.

The main logic behind Pass 1 is applying every element of the parsed lines array against a
switch statement. This switch statement handles the logic for what should be done for each
operation that requires an action.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961690799345694/pasted_image_0_2.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

Here is a brief overview of what happens during each operation:

- START
  - Current control section is set to the name of the program.
  - Symbol table entry for this control section is initialized.
  - Default program blocks entry is initialized.
- END
  - Literal array is iterated over and added to the end of the program.
  - The current program block length is set.
- EXTREF
  - External references are added to the symbol table in a unique area dedicated to
    external definitions. Later used during the translation process.
- EXTDEF
  - External definitions are added to the symbol table in a unique area dedicated to
    external definitions. Later used during the translation process.
- CSECT
  - Changes the control section.
  - Add all literals in the current array to the end of the previous control section.
- USE
  - Changes the current program block.
  - Either resumes a previous block, or starts a new one depending on the operand.
- RESW/RESB/BYTE/WORD
  - Increments location counter by the related amount depending on the operation.
- BASE
  - Does nothing except set the location counter for the current line to nothing, to
    indicate that this line does not generate object code.
- LTORG
  - Iterates over the literal array and adds each literal starting at the current location.
- EQU
  - Handles related EQU operations and arithmetic.
- \*
  - Does nothing
- MACRO
  - Creates macro definition, fills out defTab, namTab, and argTab with respective
    info.
- MEND
  - Does nothing as the previous MACRO operation logic runs until it sees MEND.
- DEFAULT
  - This is called if no other switch condition fits the operation.
  - This either expands the macro, if the macro is being called, or it simply
    increments the location counter if necessary.

After Pass 1 completes iterating over the array, it finalizes the program blocks length, and
returns the program blocks array, symbol table, and lines with location counters to the
assembler. The assembler then immediately begins on Pass 2.

## Pass 2

The goal of this pass is to generate the object code for each instruction, and use it to generate
the object program. The object code for an SIC-XE instruction can be generated in four different
formats, each format can vary in size, fields, and addressing modes. Addressing modes tells the
machine running the program how to access and operate on different memory locations. for
example if the instruction is utilizing immediate addressing, where the value for the instruction is
provided within the object code, such as the operand #100, where 100 is the value for the
instruction, or if the instruction is utilizing another form of addressing where the value needs to
be fetched from another place in memory.

Due to these different methods of addressing, generating object code is one of the most
complicated parts of this implementation of the assembler. Any small mistakes can result in an
object code being generated incorrectly.

Pass 2 utilizes a unique system implemented for this assembler called a program state. It is
used to indicate the current state of the program, and is used by the many parts that make up
Pass 2.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961690467991572/pasted_image_0_3.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

To begin Pass 2, the assembler invokes the generate object code function, and passes the
parsed lines which includes location counters, as well as the symbol table and program blocks.
Because Pass 2 is spread out across multiple processing areas, we need a central place to
store the current state of some key variables:

- Current control section
- Current block
- Symbol Table
- Program Block array
- Base register

The program state is implemented in a very simple manner, with getters and setters for each important state member.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961690174402570/pasted_image_0_4.png?width=889&height=1070'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

When Pass 2 begins, it adds the symbol table and the program block array to the state. The
next step is for the assembler to begin iterating over the parsed lines from Pass 1. The base
logic for this is similar to the logic for Pass 1, where each array element is applied against a
switch statement to handle each operation which has an applicable action.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961689293590598/pasted_image_0_5.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

Here is a brief overview of what happens during each operation:

- START
  - Sets the program state for the current control section and the current program
    block.
- BYTE/WORD
  - Generates the object code for a BYTE/WORD instruction if applicable.
- BASE
  - Sets the base register in the program state.
- CSECT
  - Sets the program state for the current control section and the current program
    block.
- USE
  - Sets the current program block in the program state.
- \*
  - Generates the object code for the literal.
- DEFAULT
  - The majority of the processing is spent here. This is the area where the object
    code for the majority of the instructions is generated.
  - First, the operation code for the respective operation is generated.
  - Next, the operand address, instruction format, and if it is a format 2 instruction,
    r1/r2 have values, are computed.
  - The flags are then computed by passing the operation, operand, operand
    address, format, and location counter. These flags are used to determine the
    addressing modes.
  - Finally, the object code is generated by invoking a function which serves as a
    router to handle the object code generation for each format.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961689004179456/pasted_image_0_6.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961688559595561/pasted_image_0_7.png?width=576&height=1068'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

This function routes the assembler to another function via a switch statement which generates
the respective object code. In this implementation, the v4 format is handled by the v3 function,
as the difference between v4 and v3 is very little, and v3 has special conditions which adapt to a
v4 format. This was done to avoid redundant code.

The generation of the object code is done by checking the flags provided, and routing the
assembler to the code to generate the object code that follows the rules decided by the flags.
Due to the complexity of making this simple, it is currently just an if-else-if chain for matching
flags. In the future, this would be an area to re-write and be made more simpler for readability
and robustness.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961688232431736/pasted_image_0_8.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961687838163055/pasted_image_0_9.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

In an attempt to make the code more readable and less complex, much of the operations to
convert the operation code, flags, and operand address to binary from hex, and to object code is
made into separate functions. These functions are also simple, and moving them away from the
main control flow helps lessen the large amount of operations being done in one code area.

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961705206792302/pasted_image_0_10.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

<img
  src={
    'https://media.discordapp.net/attachments/944583585048956928/1055961704934150174/pasted_image_0_11.png'
  }
  alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

After the object code is generated for a line, two functions are invoked, one for generating text
records, and one for generating modification records. If applicable to each context, the
assembler will automatically add the text records and modification records to an array of objects.
These text record objects include object code, the start address of the record, and the current
length of the line. The modification records include the start address, control section (if
applicable), and length of the object code for that line.

While the applicable lines are being added to the text records, if the current program context
changes, such as the control section is changed, the object program up until that point is
automatically generated and is kept in a local variable. This variable is later retrieved by the
assembler in the Post Processing phase.

## Post Processing

The Post Processing sequence is very simple, and mostly consists of the process of the
assembler building the final object program by combining each necessary part, and then writing
the object program and solution files to an output directory.

The assembler completed Pass 2 with the array of lines from before now including object code,
which can then be written to a solutions file. The assembler then calls a function to build out the
remaining object program

<img
  src={'https://media.discordapp.net/attachments/944583585048956928/1055961704636350516/pasted_image_0_12.png?width=738&height=1069'}

alt="Image alt"

style={{
    display: 'block',
    marginLeft: 'auto',
    marginRight: 'auto',
}}

/>

The final step is to write the files. For the solution file, the assembler loops over each line in the
array and writes it to a file, separating items in the objects by tabs and lines by new lines. The
object program code is already separated by spaces and new lines, and is simply written to an
object program file.

Once this is completed, the Post Processing phase cleans up all global variables for further
assembling.

## Implementation Process

The implementation for this assembler was met with a lot of hardship regarding debugging. The
majority of the time spent on the assembler was debugging two areas, the flag generation, and
the object program generation.

Flag generation seems to be simple, but can get quite complicated after considering all of the
different addressing modes and varying ways to generate object code. I spent lots of time
re-reading section 2.2-2.3 in the textbook, trying to find reasons for why my object code is not
correct. After hours of debugging, I was able to resolve my bugs regarding flags and arrived at
the current flag function. I actively worked towards making it more robust and simpler, but
struggled a lot.

Another large hurdle was adding new features, such as macros, control sections, and program
blocks, without running into issues with breaking previous features. This became very messy
very fast when all three methods were implemented. This resulted in me having to re-write the
design of the assembler to the current program state method, which helped tremendously as it
centralized where the state of some important variables are.


SIC-XE Assembler Implementation in JavaScipt

sol-trees


This is the first part in a two part series about tree implementations in solidity. In this first part, we will be going over the basics of trees and implementing one of the most basic of trees, the binary search tree.

We will first talk about what trees are and why we use them, some basic overview on time complexity, and then we will go analyze an implementation in solidity.

# What are trees?

A tree is an abstract data structure where data is stored in a hierarchical tree structure in the form of nodes that are linked to other subtrees. A tree has a root node, and nodes that are linked to it are called children nodes. Let us look at an example:

<img
  src={
    'https://images.mirror-media.xyz/publication-images/rfbjAw-eBjgQ4tTPzxpeL.png?height=474&width=640'
  }
  alt="Image alt"

style={{
        backgroundColor: 'white',
    }}
/>

In this tree, the Student node is the root of the tree. It’s children are Name, Address, ID, and Course, this group of nodes are also called siblings because they share the same parent.

Some trees have special properties that make them useful. The binary search tree is the most common example. It has several rules on how it works:

- Each node can have a maximum of two children nodes connected to it

- Nodes being inserted must be comparable in some way, for example, 1 < 2

- When inserting a number, all the numbers to the left of it must be smaller, and all of the numbers to the right of it must be bigger

The last rule is the most important. Here is an example a binary search tree:

<img
  src={
    'https://images.mirror-media.xyz/publication-images/zbds7tSyihBJN3EQKirIs.png?height=521&width=755'
  }
  alt="Image alt"

style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',
width: '50%',

    }}

/>

Start at the root of the tree, and look at the left and right sub tree. The left node is 8, which is smaller than 10, and the right node is 12, which is bigger then 10. You might be able to see where we are going with this.

# Why do we use trees?

To understand why we use trees, it is good to have a basic overview of time complexity in computer algorithms.

Let us say that we want to iterate over an array once, printing each value while we are doing it. That would look something like this (pseudo code):

```solidity
Array a;
n = a.length;
for (i=0; i<n; i++)
  print(a[i]);
```

Lets declare some things:

- The array has length of 100
- It takes 1 unit for each iteration, lets say this unit is in seconds.

Overall, we are iterating over this array N times, which is commonly declared with the notation O(n).

> O(n) means that the time complexity of the algorithm is directly proportional to the size of the input. We wont go over the background of the notation in this article. Just imagine if N is 100 it will take O(100) units for the algorithm to execute, which is 100 seconds in this case.

Now, let us look at another example like the one above, but instead with a nested for-loop:

```solidity
Array a;
n = a.length;
for (i=0; i<n; i++)
   for (x=0; x<n; x++)
      print(a[x]);
```

Here, our top for-loop will iterate N times, and our bottom for-loop will iterate N times. Combining them, we get N\*N, or N^2 times. This time complexity is denoted as O(N^2), which means this algorithm will take 10,000 units to come to completion.

What does this have to do with trees?

The problem of time complexity originated with a simple idea: lets say we have an array of 1000 items, and want to sort it. There is a simple way to do this, bubble sort:

```solidity

for (int max = elements.length - 1; max > 0; max--) {
    boolean swapped = false;
    for (int i = 0; i < max; i++) {
        int left = elements[i];
        int right = elements[i + 1];
        if (left > right) {
            elements[i + 1] = left;
            elements[i] = right;
            swapped = true;
        }
    }
    if (!swapped) break;
}

```

Bubble sort has a worst case time complexity of O(N^2). That means if we want to sort 10000 items, it will take 10000^2 units to sort it. With computers, this can be done almost instantly. However, the issue arises when we are sorting arrays with large N’s. For example, in C++, sorting an array of 1 million integers can take up to an hour.

Commonly when talking about time complexity, we are attempting to describe the worst possible time for an algorithm to take. There is a chance that the majority of an array is sorted already, but we care more about the worst case than the best case.

There are much better ways to sort an array, including other algorithms, and also other data structures. This is where the binary search tress come in.

When inserting a number into a BST (Binary search tree), the number gets sorted into the tree. This allows operations on the BST to be efficient, and sorting itself to be more efficient.

<img
  src={
    'https://images.mirror-media.xyz/publication-images/XuTsRsDym6JZm4l4DLTTt.png?height=137&width=653'
  }
  style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',

    }}

alt="Image alt"
/>

Take a look at the average case of Insert and Search, versus the worst case. The reason for the differences is because of an occurrence where numbers can be inserted in sorted order, for example:

<img
  src={
    'https://images.mirror-media.xyz/publication-images/SwhSSQmrYxTgIKeTnVEpA.png?height=444&width=402'
  }
  alt="Image alt"

style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',
width: '50%',

    }}

/>

This means that to access the 7 node, it will take O(n) time as you will have to go over all the nodes in the tree first.

A subset of the binary search tree exists that solves this issue, and achieves O(log n) worst case time complexity for insert and search. We will explore these and their implementation in solidity in part two of this series.

# Binary Search Tree in Solidity

Why would we write a binary search tree in solidity? Having an efficient way to sort data in a programming language where efficiency directly saves you money (gas) is definitely something that is crucial.

Every iteration over an array costs gas, and for large array’s it is possible for you to run out of gas while sorting it. We move this gas from the sort operation to the insert operation.

[Github Repo](https://github.com/d3or/sol-trees)

The way nodes are stored is similar to how we did it with our stack implementation via linked lists, where we store our actual nodes in a mapping, with each node having its own unique id that other nodes can point to it via.

```solidity
   struct Node {
        uint256 value;
        bytes32 left;
        bytes32 right;
    }
```

Here is our node struct, and it is rather simple. It stores a uint256 value, and two bytes32 values, left and right. These are used to indicate the two children of the node, and are set to the address ID of those nodes.

Next we have the address of our root as a state variable, and our mapping to store our nods:

```solidity
    mapping (bytes32 => Node) private tree;

    bytes32 private rootAddress;
```

Now, we have our state variables set up. Next, we look at insertion. Hang tight, this might look complicated but it is actually relatively simple!

```solidity
function insert(uint256 value) public {
        Node memory root = tree[rootAddress];
        // if the tree is empty
        if (root.value == 0) {
            root.value = value;
            root.left = 0;
            root.right = 0;
            tree[0] = root;
            rootAddress = generateId(value, 0);
            tree[rootAddress] = root;
        } else {
            // if the tree is not empty
            // find the correct place to insert the value
            insertHelper(value, rootAddress);
        }
}
```

First, we attain the root of the tree by using the state-variable root address to access the root node stored inside our mapping.

Next, we check if the tree is empty. If it is empty, we create the root node, generate its unique id, and put it into the mapping.

In this example, the root node should not have a value less than 0. We are using unsigned 256 bit integers. Thus, a node can not have the value of 0.

If the tree is not empty, we use the function insertHelper, and pass the value and the root address where it recursively finds the right place to insert the node into the tree.

```solidity
  // helper function for insert
    function insertHelper(uint256 value, bytes32 nodeAddress) internal {
        Node memory node = tree[nodeAddress];
        if (value < node.value) {
            if (node.left == 0) {
                insertNode(value, nodeAddress, 0);
            } else {
                insertHelper(value, node.left);
            }
        } else {
            if (node.right == 0) {
                insertNode(value, nodeAddress, 1);
            } else {
                insertHelper(value, node.right);
            }
        }
    }
```

This function checks if the node’s value is less than the current node, if so, if the left child is empty, it inserts the node into that position. If it is less but the node is not empty, it then calls the function again but with that new node, until it finds an empty spot. It does the same operation for if the value is bigger than the current node.

The insert node function is rather simple, it takes three parameters, the value, the address to put the node, and a 0 or 1 value to indicate where to put the node, left or right.

```solidity
function insertNode(uint256 value, bytes32 nodeAddress, uint256 location) internal {
        Node memory parentNode = tree[nodeAddress];
        bytes32 nodeId = generateId(value, nodeAddress);
        if (location == 0) {
            // if the value is less than the current node
            parentNode.left = nodeId;
        } else {
            // if the value is greater than the current node
            parentNode.right = nodeId;
        }

        // update the tree
        tree[nodeAddress] = parentNode;
        tree[nodeId] = Node(value, 0, 0);
    }
```

This article is a lot longer than I was expecting, so I will skip going over how deletion works and instead go over to how to display the tree in order and how to find elements.

You can look at the deletion function in the source code, there are detailed comments on how it works.

```solidity
 // inorder traversal
    function displayInOrder() public {
        displayInOrderHelper(rootAddress);
    }

  // recursive helper function for inorder traversal
  function displayInOrderHelper(bytes32 nodeAddress) internal {
      Node memory node = tree[nodeAddress];
      if (node.left != 0) {
          displayInOrderHelper(node.left);
      }
      console.log(node.value);
      if (node.right != 0) {
          displayInOrderHelper(node.right);
      }
  }
```

This is also pretty simple! It recursively goes down the tree in ascending order. The code is pretty self explanatory.

I was using hardhat’s console.log feature when displaying the tree. This is the base algorithm for displaying a tree in order, and it can be expanded upon by making a non-recursive version via a stack, that way it will be easier to return the values.

Finding elements also works similarly:

```solidity
  // search for a value in the tree
    function findElement(uint256 value) public view returns (bool) {
        return findElementHelper(value, rootAddress);
    }

    // recursive helper function for findElement
    function findElementHelper(uint256 value, bytes32 nodeAddress) internal view returns (bool) {
        Node memory node = tree[nodeAddress];
        if (node.value == value) {
            return true;
        } else if (node.value > value) {
            if (node.left == 0) {
                return false;
            } else {
                return findElementHelper(value, node.left);
            }
        } else {
            if (node.right == 0) {
                return false;
            } else {
                return findElementHelper(value, node.right);
            }
        }
    }

```

Take a look at the repo on GitHub to see the rest of the functions and ways to interact with the tree.

# Conclusion

We barely scratched the surface of what is possible with trees. In the next part, we will be looking into implementing an alternative search tree that has worst-case time complexity of search of O(logn)!

I hope you were able to learn something from this article! If you have any comments or questions feel free to direct message me on twitter @Deor.


Solidity Trees (Part 1)

hardhat-gas-trackooor

ll-stack-solidity


Ok, cool. Now what are all these words. A stack? A linked list? Solidity?

Lets start off with going over linked lists.

If you are already familiar with linked lists and stacks, you can skip these parts and go to the end where the solidity code is discussed.

# What is a linked list?

A linked list is a data structure that is made up of nodes. Every node contains two things: data, and a pointer to the next node in the list. In this scenario, we are using a single linked list, which is a linked list that only points to the next node.

There are other types of inked lists, such a doubly linked lists, where each node points to the node in front of it and behind it.

<img
  src={
    'https://images.mirror-media.xyz/publication-images/0jSZqxOrrNrenhVLwc3B0.png?height=400&width=600'
  }
  style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',

    }}

alt="Image alt"
/>

## Why not just use an array?

Linked lists have several advantages over traditional arrays.

For example, when inserting an element at a position in an array, you normally need to shift over all of the elements to the right. On the other hand, to insert data into a linked list you just need to change two pointers: the pointer for the node at Y-1; and the pointer for the current node to point to the node at Y+1.

<img
  src={
    'https://images.mirror-media.xyz/publication-images/7vdOFPzww7YxygHY0PsmT.png?height=349&width=553'
  }
  style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',

    }}

alt="Image alt"
/>

Deletion works similarly.

Also, because linked lists are dynamic and memory is allocated dynamically according to our needs, we do not waste any memory compared to arrays—which waste memory unless they are full.

# What is a stack?

A stack is a data structure that contains a collection of items "stacked" on top of each other with two main operations: Push and Pop. Push adds another item onto the stack, and Pop removes the top item off the stack.

Think of a stack like a pile of plates. When you “Push”, you are adding a plate onto the stack, and when you “Pop”, you are taking that plate off.

<img
  src={
    'https://images.mirror-media.xyz/publication-images/r8b8A9VCh4hwuukVv1S7Z.png?height=687&width=1140'
  }
  style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',

    }}

alt="Image alt"
/>

## How are stacks useful?

Stacks can be used for many things! In lower level languages, there are no methods such as .reverse() that you can easily use on strings (solidity does not have .reverse!). Instead, to reverse a string, we can use stack and add each letter of the word sequentially. Afterwards, by popping each letter off the stack we reverse the word.

This is just one, small example. There are plenty more like: storing history (ctrl-z); recursion'; evaluating certain mathematical expressions (Shunting Yard Algorithm);

# Coming together

To create a stack, you can use a single linked-list, where every node has a pointer to the node “under” it.

<img
  src={
    'https://images.mirror-media.xyz/publication-images/Jpev5byRvmqHKmi6nWOe_.png?height=224&width=720'
  }
  style={{
display: 'block',
marginLeft: 'auto',
marginRight: 'auto',

    }}

alt="Image alt"
/>

# Solidity Implementation

First, we need to define a struct for a Node, it should contain a value and a next pointer to point to the next node.

When implementing a linked list, you usually use a memory address pointer when defining a node. For example in C++ you can define the Node as a pointer to another Node class instance!

Example of Node class in C++:

```cpp
class Node {
    private:
        int data;
        Node * next;
    public:
        Node(int data) {
            this->data = data;
            this->next = NULL;
        }
        int getData() {
            return this->data;
        }
        Node * getNext() {
            return this->next;
        }
        void setNext(Node * next) {
            this->next = next;
        }

};
```

In solidity, it is not possible to do this in the same manner. This is because Solidity does not allow recursive structs:

```solidity
    struct Node {
        uint256 value;
        Node next;
    }
```

So instead of pointing to the memory address of the next node, our struct should contain a key in a mapping which points to the next node:

```
 struct Node {
        uint256 value;
        bytes32 next;
    }

 mapping (bytes32 => Node) nodes;
```

The ID for the next node should be something unique, for example taking the hash of the old top’s value, id, and the current block timestamp. By using the OldTop’s next-id, we can make sure that we won’t get overlapping keys within the same block:

```solidity
keccak256(
        abi.encodePacked(
             OldTop.value,
             OldTop.next,
             block.timestamp
        )
);
```

Then, we take this ID and map it to the the old top node. Here is the main code for push:

```solidity
 function push(uint256 value) public {
        Node memory node;
        node.value = value;

        if (Top.next == 0) {
            // code if the stack is empty
        }  else {
            Node storage OldTop = Top;
            node.next = keccak256(
                abi.encodePacked(
                    OldTop.value,
                    OldTop.next,
                    block.timestamp
                )
            );
            nodes[node.next] = OldTop;
            Top = node;
        }
    }
```

So, what is happening in this code block? Lets break it down.

First, we assigned the current Top value in the stack to OldTop. Then, we create an ID based off of the OldTop values and the current block timestamp.

Next, we assign this ID to the new Top node, and then we map this ID to the OldTop node in the mapping. After this, we assign the Top node to the new node that is being pushed to the stack.

This solidity implementation of a linked list works without a counter to count the number of nodes and to use as a key for in the mapping to other nodes in the list.

The way pop works is very simple:

```solidity
  function pop() public returns (uint256) {
        require(Top.next != 0, "Stack is empty");

        Node storage oldTop = Top;
        uint256 oldValue = Top.value;

        Top = nodes[oldTop.next];
        return oldValue;
    }
```

If the stack is not empty, the ID for the top node is used to get the node under it, and then that node becomes the new top.

Also, it is usually a common practice to return the value of the node being popped off the stack, which is why we return the oldValue at the end.

That’s all folks! There are some other functions such as clear, peek, isEmpty, and size that are not as important to the core design so I chose not to go over them. If you want to see how they work head over to the repo!

[ll-stack-solidity repository](https://github.com/d3or/ll-stack-solidity)


Solidity Stacks & Linked Lists

eth-vanity-gen


Something has always existed. According to physics, there can never be true physical nothingness—though there can be times when existence resembles nothing, such as a vacuum (the state of minimum possible energy) (Phys.org). Creating a space where there are no quantum fluctuations requires an enormous amount of energy, and there would be a remnant of that energy in that space afterwards if the fluctuations were flushed out, plus an unstable environment (1veritasium). Even on computers, deleted data is not actually tossed away, by rather written over.

# h1 Heading

## h2 Heading

### h3 Heading

#### h4 Heading

##### h5 Heading

###### h6 Heading

## Horizontal Rules

---

## Emphasis

**This is bold text**

**This is bold text**

_This is italic text_

_This is italic text_

~~Strikethrough~~

## Blockquotes

> Blockquotes can also be nested...
>
> > ...by using additional greater-than signs right next to each other...
> >
> > > ...or with spaces between arrows.

## Lists

Unordered

- Create a list by starting a line with `+`, `-`, or `*`
- Sub-lists are made by indenting 2 spaces:
  - Marker character change forces new list start:
    - Ac tristique libero volutpat at
    * Facilisis in pretium nisl aliquet
    - Nulla volutpat aliquam velit
- Very easy!

Ordered

1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa

4. You can use sequential numbers...
5. ...or keep all the numbers as `1.`

Start numbering with offset:

57. foo
1. bar

## Code

Inline `code`

Indented code

    // Some comments
    line 1 of code
    line 2 of code
    line 3 of code

Block code "fences"

```
Sample text here...
```

Syntax highlighting

```solidity
var foo = function (bar) {
  return bar++;
};

console.log(foo(5));
```

## Tables

| Option | Description                                                               |
| ------ | ------------------------------------------------------------------------- |
| data   | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default.    |
| ext    | extension to be used for dest files.                                      |

Right aligned columns

| Option |                                                               Description |
| -----: | ------------------------------------------------------------------------: |
|   data | path to data files to supply the data that will be passed into templates. |
| engine |    engine to be used for processing templates. Handlebars is the default. |
|    ext |                                      extension to be used for dest files. |

## Links

[link text](http://dev.nodeca.com)

[link with title](http://nodeca.github.io/pica/demo/ 'title text!')

Autoconverted link https://github.com/nodeca/pica (enable linkify to see)


Something has always existed. According to physics, there can never be true physical nothingness—though there can be times when existence resembles nothing, such as a vacuum (the state of minimum possible energy) (Phys.org). Creating a space where there are no quantum.

software engineer focused on creating efficent and performant software

prev founder of module, acquired by reservoir.

currently fulltime backend engineer at reservoir, helping build trading infrastructure for the future of digital assets.

legend

📝 note
📘 blog
🗞️ external blog
📂 repository
🐦 tweet

📝 Apr 18 2024 - how to sign an already hashed message with ethers

🐦 Apr 9 2024 - sweeping unclaimed bridges on ethereum

📝 Apr 9 2024 - fix for: “the chromium binary is not available for arm64.”

📝 Apr 6 2024 - fix for "originalkeywordkind" has been deprecated since v5.0.0 and can no longer be used

📂 Mar 31 2024 - single-twitter-tab

📝 Mar 30 2024 - pulling docker container from private registry in kubernetes

🐦 Mar 28 2024 - ethereum history: gas cost changes for memory usage

🐦 Mar 27 2024 - ethereum history: gas exploit before homestead

🐦 Mar 26 2024 - the true cost of 'gasless' erc20 transfers

📝 Mar 23 2024 - fix for openapi-typescript issue with empty swagger spec components.schema object

📝 Mar 23 2024 - fix: error [err_require_esm]: require() of es module string-width

📘 Mar 16 2024 - expose a local k3s server, without exposing your internet

📝 Jul 27 2023 - uwebsockets.js pong behavior for maintaining connection status

📂 Jun 26 2023 - castle

🐦 Mar 21 2023 - module acquired by reservoir

🐦 Nov 14 2022 - sbf_ftx deleting tweets and tweeting to offset his total tweets count

📂 Oct 25 2022 - nft-anomaly-detector

📂 Oct 25 2022 - nft-sniper

🗞️ Oct 4 2022 - module edge - faster nft images

🗞️ Sep 23 2022 - fulltx - an easier way to index ethereum

🗞️ May 21 2022 - ingress fanout for kubernetes

📂 May 21 2022 - ingress-fanout-tutorial

📝 May 13 2022 - nft metadata alternatives

🗞️ April 18 2022 - fastify redis cache plugin

📂 April 18 2022 - fastify-redis-cache

🗞️ April 2 2022 - fastify vs express

📂 March 14 2022 - sic-xe-assembler.js

📘 March 14 2022 - sic-xe assembler implementation in javascipt

📂 March 14 2022 - sol-trees

📘 March 14 2022 - solidity trees (part 1)

📂 Feb 19 2022 - hardhat-gas-trackooor

📂 Feb 19 2022 - ll-stack-solidity

📘 Feb 19 2022 - solidity stacks & linked lists

📂 Feb 13 2022 - eth-vanity-gen