DEV Community: abhinav the builder

CTF basics!

abhinav the builder — Thu, 11 May 2023 15:17:41 +0000

Quick Reference for most basic CTFs

Basic Syscalls

fork creates a new process by duplicating the calling process, while exec replaces the current process image with a new process image.
fork creates a child process that is a clone of the parent process, while exec loads a new program into the current process.
The child process created by fork initially shares the same memory space as the parent process, while the exec system call loads a new program into a new memory space.
fork returns the process ID of the child process to the parent process, while exec does not return to the calling process.
fork is often used to create a new process that performs some task independently of the parent process, while exec is used to start a new program or to change the behavior of the current process.
The exec family of system calls includes several variants, such as execl, execv, execle, and execvp, which differ in the way they accept arguments and how they search for the new program.
The choice between fork and exec depends on the specific needs of the application and the desired behavior of the new process.

PLTs and GOTs

PLT stands for Procedure Linkage Table, and it is a data structure used in dynamic linking to call functions in shared libraries.
GOT stands for Global Offset Table, and it is another data structure used in dynamic linking to resolve the addresses of functions and data objects in shared libraries.
When a program calls a function in a shared library, the PLT is used to redirect the call to the GOT, which then resolves the address of the function and redirects the call to the actual function code.
The PLT and GOT are both created by the linker during the dynamic linking process, and they are stored in a read-only section of the program's memory.
The use of PLTs and GOTs helps to reduce the size of shared libraries and allows them to be shared across multiple programs in memory, improving memory efficiency.

x86 Stacks:

The x86 architecture has two stacks: the user stack and the kernel stack.
The user stack is used to store local variables and function call parameters in user-mode programs.
The kernel stack is used to store kernel-level variables and function call parameters in kernel-mode programs.
The stacks grow downwards in memory, with the stack pointer pointing to the top of the stack.
The stack pointer is maintained in the ESP (Extended Stack Pointer) register.
Pushing data onto the stack decreases the ESP value, while popping data off the stack increases the ESP value.

x86 Registers:

The x86 architecture has several types of registers, including general-purpose, segment, and control registers.
General-purpose registers are used for arithmetic and logic operations, and include EAX, EBX, ECX, EDX, ESI, EDI, and EBP.
The instruction pointer (IP) register stores the memory address of the next instruction to be executed.
Segment registers are used to point to different segments of memory, such as code or data segments.
Control registers are used to control system behavior, such as the flags register (EFLAGS), which contains status flags that indicate the result of arithmetic and logic operations.
The x86 architecture also includes several special registers, such as the floating-point unit (FPU) stack and the debug registers, which are used for debugging purposes.
- Rax - accumulator: arithmetic operations and function return values.
- Rbx - base: memory addressing and as a general-purpose register.
- Rcx - counter: loop iterations and function arguments.
- Rdx - data: Data register used for arithmetic operations and as a general-purpose register.
- Rsi: Source index register used for string operations and memory addressing.
- Rdi: Destination index register used for string operations and memory addressing.
- Rbp: Base pointer register used for accessing function parameters and local variables on the stack.
- Rsp: Stack pointer register used for pointing to the top of the stack.

	Stack	Heap
Purpose	Used to store function calls and values	Used for dynamic memory allocation
Data structure	Last In First Out (LIFO)	Not organized, data is randomly stored
Memory allocation	Automatic	Manual, managed by the programmer or operating system
Memory allocation/deallocation time	Very fast	Slower than stack
Size limit	Fixed, smaller than heap	Not fixed, larger than stack
Access speed	Fastest	Slower than stack

Stack overflows

Most basic type of attack you must understand - do not skip! Stack overflow is a type of Buffer overflows. Every process has a memory map. Each memory map has 4 areas: Application, Heap, Libraries, Stack. RBP tells you where the stack “ends”, RSP tells you where the stack “starts”. Stack grows in one direction: either “up” or “down” - depending on convention. Every function gets a stack frame.

Buffer overflow attacks occur when an attacker sends more data than a program has allocated memory for, which can overwrite adjacent memory areas, including the stack. Here is how a buffer overflow attack works on stacks using a simple C example:

In C, a stack is used to store local variables and function calls. The stack grows downward from high memory addresses to low memory addresses.
A buffer is a temporary storage area in memory that can hold a set amount of data. When an attacker inputs more data than the buffer can hold, it overflows into adjacent memory areas, including the stack.
An attacker can exploit this vulnerability by injecting malicious code into the overflowed buffer, which can alter the program's control flow, hijack its execution, or execute arbitrary code.
Here is an example vulnerable program in C:

#include <stdio.h>
#include <string.h>

void vulnerable_function(char* input) {
    char buffer[10];
    strcpy(buffer, input);
    printf("Input: %s\n", buffer);
}

int main() {
    char input[20];
    printf("Enter input: ");
    gets(input);
    vulnerable_function(input);
    return 0;
}

In this program, vulnerable_function() copies the input string into a buffer that is only 10 bytes long. If the input string is longer than 10 bytes, it will overflow the buffer and overwrite adjacent memory areas.

An attacker can send a payload to exploit this vulnerability, such as:

char payload[] = "AAAAAAAAAAAAAAAAAAAA\xef\xbe\xad\xde";

In this payload, the first 20 bytes are A characters, which will fill up the buffer. The last four bytes \xef\xbe\xad\xde will overwrite adjacent memory areas and change the program's control flow to execute arbitrary code.

An attacker can send the payload to the program via input, and it will execute arbitrary code:

Enter input: AAAAAAAAAAAAAAAAAAAA����
Segmentation fault

In this case, the program crashes due to a segmentation fault caused by the overwritten memory areas. But an attacker can use this technique to execute arbitrary code, which can be malicious and damaging. I’ve kept the example short, but an attacker might use /bin/sh little endian representation.

Little Endian: I’m not talking about my little brother. Little endian is a ridiculous looking way to pass values to x86. This is the following for /bin/sh. It is least significant bit first.

char *shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
          "\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"; // little endian representation of bin/sh payload shellcode

👉 Reiterating!

The attacker identifies the memory location of the return address on the stack that controls the program's execution after the vulnerable function completes.
The attacker prepares a payload that includes a NOP sledge followed by shellcode. A NOP sledge is a series of no-operation instructions (\x90 bytes) that serve as a buffer between the overwritten return address and the shellcode. This buffer is important because it allows the processor to transition smoothly from the return address to the shellcode, without encountering any invalid instructions in the process.
The attacker calculates the number of NOP bytes needed to reach the shellcode. Let's say the shellcode is 23 bytes long, and the return address is located 32 bytes after the start of the buffer. The attacker would need to add 9 NOP bytes to the payload to reach the shellcode (32 bytes - 23 bytes = 9 bytes).
The attacker constructs the payload by filling the buffer with A characters (or any other character that can be easily identified in the debugger), followed by the NOP sledge and the shellcode. The return address is set to the location of the NOP sledge within the buffer.
The attacker sends the payload to the program, which will copy the input string into the buffer and overwrite the return address with the address of the NOP sledge.
When the vulnerable function completes and tries to return to the overwritten address, it will start executing the NOP sledge, which serves as a buffer to reach the shellcode. The shellcode will then be executed, allowing the attacker to take control of the program and execute arbitrary instructions.

Ret2Libc: What if there’s an exit(0)

Return-to-libc is a technique used in computer security to exploit vulnerabilities in a program that allow an attacker to control the contents of the program's stack, even if they cannot execute injected code. The basic idea is to use existing code in the program, specifically functions in the libc library, to perform the attacker's desired actions.

Example: If the vulnerable function ends with an exit() call, it will terminate the program, and the attacker will not be able to gain control of the program's execution flow. However, if the attacker can overwrite the exit() function's return address with the address of their malicious code, they can redirect the program's execution to that code before the program exits, giving them control.

Here's an example of how an attacker could still use a buffer overflow attack to redirect program execution to their shellcode even if the vulnerable function ends with an exit() call:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void vulnerable_function(char* input) {
    char buffer[10];
    strcpy(buffer, input);
    printf("Input: %s\n", buffer);
    exit(0); // vulnerable function ends with an exit call
}

int main() {
    char input[20];
    printf("Enter input: ");
    gets(input);
    vulnerable_function(input);
    return 0;
}

In this modified program, the vulnerable_function() ends with an exit(0) call. However, an attacker can still exploit the buffer overflow vulnerability to redirect program execution to their shellcode. They can overwrite the exit() function's return address on the stack with the address of their shellcode.

To do this, the attacker can construct a payload that includes a "return-to-libc" attack. This type of attack replaces the return address on the stack with the address of a function in a shared library, such as system() or execve(), which the attacker can use to execute arbitrary shellcode. Here is an example payload that would execute /bin/sh using the system() function:

#include <stdio.h>
#include <stdlib.h>

int main() {
    char payload[] = "AAAAAAAAAAAAAAAAAAAABBBBCCCC\x18\xa0\x04\x08\xed\x1d\x83\x04/bin/sh";
    printf("Payload length: %d\n", strlen(payload));
    ((void (*)())payload)();
    return 0;
}

In this payload, the first 20 bytes are A characters, which will fill up the buffer. The next 8 bytes are the original return address of vulnerable_function(). The next 4 bytes are the address of the system() function in the program's shared library (this address can be obtained using a debugger or other tools). Finally, the last 8 bytes are the argument to the system() function, which is the string /bin/sh.

When the payload is executed, it will overflow the buffer in vulnerable_function() and overwrite the return address on the stack with the address of the system() function. The system() function will be called with the argument /bin/sh, which will execute a shell with root privileges, giving the attacker complete control over the system.

So, in summary, even if the vulnerable function ends with an exit() call, an attacker can still use a buffer overflow attack to redirect program execution to their shellcode by overwriting the return address of the exit() function on the stack.

Another example: Let's say we have a vulnerable program that takes input from the user and passes it to a function called strcpy without any bounds checking. This creates a buffer overflow vulnerability that we can exploit.

Our goal is to execute a command on the system using the system function from the libc library, with our own argument string. However, we can't inject any code of our own.

Instead, we can use the buffer overflow to overwrite the return address on the stack, which determines where the program will jump to after the strcpy function returns. We can set the return address to point to the system function in the libc library, and arrange the stack to include our desired argument string.

So, when the vulnerable program returns from the strcpy function, it will jump to the system function instead of continuing with its normal execution. The system function will then execute the command we specified with our argument string.

This attack works because the system function and other useful functions like execve are commonly used in programs and are present in the libc library, which is linked into virtually all programs. However, modern defenses like stack canaries and non-executable memory have made return-to-libc attacks much more difficult to carry out.

Return Oriented Programming: Corrupting return address

Return Oriented Programming (ROP) is a technique used by attackers to execute code in a program by chaining together small snippets of existing code called "gadgets". These gadgets typically end with a "return" instruction, hence the name "return-oriented" programming. By stringing together a series of these gadgets, an attacker can create arbitrary instructions that perform their intended malicious action.

Here is a simple example of ROP:

Let's say we have a vulnerable program that takes input from the user and stores it in a buffer without proper bounds checking. The attacker can overflow the buffer with a string of their choice and overwrite the return address on the stack with the address of a gadget in the program. This gadget could be a small piece of code that performs a useful operation, such as writing a specific value to a certain memory location.

Next, the attacker can continue overflowing the buffer with additional gadgets, each ending with a "return" instruction that jumps to the next gadget in the chain. By chaining together a series of gadgets, the attacker can create arbitrary instructions that perform their intended malicious action, such as spawning a shell or stealing sensitive information.

For example, let's say the vulnerable program has a gadget that performs the instruction "mov eax, 0xdeadbeef". The attacker could overwrite the return address on the stack with the address of this gadget, and then continue overflowing the buffer with additional gadgets that perform other useful operations, such as "mov ebx, 0xcafebabe" and "int 0x80" to spawn a shell. By chaining together these gadgets, the attacker can create the arbitrary instructions needed to perform their intended action.

More videos on this topic

Stacks (https://www.youtube.com/watch?v=5iQkR69H_1M)
Buffer overflows (https://www.youtube.com/watch?v=B4v56Ns3QhQ)
ROP exploits (https://www.youtube.com/watch?v=ltEtjC6phT0) – Corrupting the return address on the stack (https://www.youtube.com/watch?v=V9lMxx3iFWU) – PLT entries and GOTs (https://www.youtube.com/watch?v=kUk5pw4w0h4) – ctor, dtors – vtable entries – Tricking the heap manager using fake chunks (https://www.youtube.com/watch?v=LsA-bYhPS6s)

More good stuff-

https://www.youtube.com/watch?v=t1LH9D5cuK4 (general format string exploits)
https://www.youtube.com/watch?v=MrI3X5dNsmo (writing payloads)
https://www.youtube.com/watch?v=HSlhY4Uy8SA (buffer overflow with shellcodes)

In you understand Hindi, The Cyber Expert is a great channel for understanding CTF basics.

To be continued.

Passwords in Solidity

abhinav the builder — Fri, 29 Apr 2022 17:55:19 +0000

Why is it needed?

Suppose you have locked liquidity on-contract which can be liquidated via withdraw() that depends on a require function and access control. If someone has access to the responsible EOA, they can withdraw funds when needed. A better way to go about this is to also have a password, so that incase of a private key leak, the hacker still has to enter a password.

How is it implemented?

User enters password, gets hashed via Keccak256 and appended with "0x" before the hash string.
User sets password via constructor when deploying (_setNewPassword())
User then can decide to check password (_testPassword()) and enter expected password and new password (since current password will be declared by on-chain data).

Solidity Code

contract onChainPassword
{
    bytes32 private globalPassword;

    constructor(bytes32 _hashedPassword) 
    {
        globalPassword = _hashedPassword;
    }

    function _checkPassword(string memory _password, bytes32 _newPassword)
        public returns (bool)
    {
        bool decision = keccak256(abi.encodePacked(_password))==globalPassword;
        _setNewPassword(_newPassword);
        return decision;
    }

    function _setNewPassword(bytes32 _newPassword) internal
    {
        globalPassword = _newPassword;
    }
}

Disclaimer

Never put Friday projects on main-net without testing extensively, I'm a scatterbrain.

Off-chain Sorting over on-chain Sorting in Solidity

abhinav the builder — Tue, 26 Apr 2022 21:49:28 +0000

This is not a unique approach but something I personally used when I had to shave off a few kilobytes off the contract size and also reduce the gas usage. In my use-case, I needed multiple sorting to decide certain winners, rankings, price distributions and such.

Now, I don't have access to a backend code to try this on when writing this, maybe I could update this later with some scaffold-eth, but this is how I would possible implement this.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.10;

contract Array {
    uint[] public arr;
    uint[] public arrSorted;
    address payable public _admin;

    constructor()
    {
        _admin = payable(msg.sender);
    }

    event sort(uint[]);

    function sortOffChain() public returns (uint[] memory)
    {
        emit sort(arr);
        return arrSorted;
    }

    function getSortedData(uint[] memory arrData) public
    {
        require(msg.sender == _admin);
        arrSorted = arrData;
    }
}

On the backend, the algorithm would look something like this -

event listener listening for sort()
calls bubbleSort() [Or whatever suits you] upon getting triggered
calls getSortedData() function with returned value of bubbleSort()

This of course shouldn't be used everywhere, but it is a quick and easy way of sorting data.

Installing Echinda-test on MacOS

abhinav the builder — Fri, 15 Apr 2022 23:13:13 +0000

TL;DR : Install Echidna binaries. We are avoiding building it from scratch. Some other day for that.

Add your Python modules to your path to allow you to use echidna dependencies. Add this to your ~/.zshrc or ~/.bashrc - or something similar.

export PATH=$PATH:/Users/abhinavmir/Library/Python/3.9/bin

Add this via source ~/.zshrc.

Now download the binaries from here: github.com/crytic/echidna/releases

Now move it into /usr/local/bin using mv echidna-test /usr/local/bin.

Once done, add export PATH=$PATH:/usr/local/bin/echidna-test to ~/.zshrc - now source ~/.zshrc.

Now, pip3 install crytic-compile.

Add export PATH=$PATH:/Users/<you>/Library/Python/<your version>/bin - but if you're on Linux, change that to wherever Python binaries are. Restart your shell.

Now, echidna-test should run with no issues.

Stolen Notes on EVM (Ethereum Virtual Machine)

abhinav the builder — Sat, 02 Apr 2022 23:00:59 +0000

Author's Notes: These are notes stolen from 10-15 of my favourite articles. I'll cite them some day, but they're easily reverse-searchable. This is probably the best singular resource on EVM apart from the papers themselves.

What is the EVM? How does it work?

At a high level, Ethereum Virtual Machine is a deterministic function that outputs a certain value for a certain input. The EVM is much like any other computer, but it specializes in running smart contracts. EVM is like JVM - but instead of using any other process virtual machine, on Ethereum we use EVM because we need things like finite determinism and gas-implementations.

The compiler design behind EVM

Solidity is a high-level language choice that compiles into bytecodes (machine readable set). Solidity is one of the more popular choices, otherwise Vyper, Flint, even C via ceagle can be your choices.

Opcodes are low-level human-readable instruction sets that are representative of the deployed/creation bytecode. This creation bytecode is used to generate the runtime bytecode. The following contract is an example.

pragma solidity ^0.8.10;
contract MyContract {
    uint i = (10 + 2) * 2;
}

For this, this is generated-

"object": "60806040526018600055348015601457600080fd5b50603f8060226000396000f3fe6080604052600080fdfea264697066735822122068ed984f1f49a5710584afd544f61110f039d04d2791e66a88e1d8914ffdff1464736f6c634300080b0033",

"opcodes": "PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x18 PUSH1 0x0 SSTORE CALLVALUE DUP1 ISZERO PUSH1 0x14 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x3F DUP1 PUSH1 0x22 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN INVALID PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x0 DUP1 REVERT INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 PUSH9 0xED984F1F49A5710584 0xAF 0xD5 DIFFICULTY 0xF6 GT LT CREATE CODECOPY 0xD0 0x4D 0x27 SWAP2 0xE6 PUSH11 0x88E1D8914FFDFF1464736F PUSH13 0x634300080B0033000000000000 "

EVM Architecture

There are two types of accounts in Ethereum: EOA (Externally owned accounts) and Smart Contracts. Both are treated similarly by the EVM, have balances and storage. Here's one of my favourite graphics for this.

Focus on the lower two blocks. When a transaction caller sends a transactiom, a module to recieve input transaction recieves the input and updates storage, while storing the arguments in the stack with the program counter. The Smart Contract bytecode, with the stack is then fed to the EVM for gas estimation via opcodes. The gas fee is deducted, and the opcode is executed. THe memory is then updated. If the transaction fails, the memory is updated.

EVM is stack-designed, so stack operations such as pop, push apply to it. The overall architecture is similar to any other FSM and instructions are implemented how they're implemented in other stack-based machines, with obvious differences.

Different implementations of the Ethereum protocol are implemented in different ways/languages such as Geth, Parity, Mist - with different add-on features, but same core structure of EVM + State + Consensus.

Memory, Storage, State and such

The Ethereum Virtual Machine has three areas where it can store data- storage, memory and the stack, which are explained in the following paragraphs.

Each account has a data area called storage, which is persistent between function calls and transactions. Storage is a key-value store that maps 256-bit words to 256-bit words. It is not possible to enumerate storage from within a contract, it is comparatively costly to read, and even more to initialise and modify storage. Because of this cost, you should minimize what you store in persistent storage to what the contract needs to run. Store data like derived calculations, caching, and aggregates outside of the contract. A contract can neither read nor write to any storage apart from its own.

The second data area is called memory, of which a contract obtains a freshly cleared instance for each message call. Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide. Memory is expanded by a word (256-bit), when accessing (either reading or writing) a previously untouched memory word (i.e. any offset within a word). At the time of expansion, the cost in gas must be paid. Memory is more costly the larger it grows (it scales quadratically).

The data in the Blockchain itself is stored via a Merkle Patricia-Trie tree Data Structure. A Patricia Trie or prefix Tree or radix Tree is an ordered structured tree, which takes the applications of usually the data it stores. A node’s position in the tree defines the key with which that node is associated, which makes tries different in comparison to binary search Trees, in which a node stores a key that corresponds only to that node.

In different implementations, the state is maintained in different ways. For example in Go-Ethereum, it is done via stateDB.go.

Is the EVM Turing-complete, why?

Turing complete machines are machines that despite any complexity of problem, will solve a problem given enough time. This is of course, an abstract idea developed using an infinite tape. EVM is quasi-Turing complete system, because the machine executes as far as the gas is provided. Gas is the fundamental fuel for the infrastructure and this solves the halting problem in a way - in that you cannot generally determine whether an arbitrary problem provided will keep running forever or not, but the gas will not allow any problem to run forever. The gas is calculated on an opcode-basis. For example, to calculate one Keccak256 cryptographic hash it will take 30 gas each time a hash is calculated, plus a cost of 6 more gas for every 256 bits of data being hashed.

What is Gas and why is it important for operations in the EVM?

Ethereum gas is unique from Bitcoin due to how pieces of code are treated on the platform. On Bitcoin, gas/fee is charged per size unit basis, but since Ethereum allows for complex, decisive code to be run on the platform, it charges gas per operation unit basis. Gas isn't a token, but rather a unit of measurement of work, like joule. Now USD <> Joule value is decided by market rate, but unit of work done is decisive and lawful (one by nature, one by code). If I set a gas fee too low with my transaction (although post update, I must set a baseFee to my txn), no node will choose to pick my transaction and add it to a Block, thus resulting in no change in the Blockchain state - which is the end goal.

Gas is important because it allows for monetization of operation. Monetization of operation means - 1. Nodes are rewarded for maintaining integrity of node, 2. There is a punishment for malicious code to cause a DOS-like attack. As disccused earlier, the gas feature of the EVM allows for the quasi-Turing complete state of the machine. Sure, you don't have an infinite tape, but gas allows for the scope of usage of tape to be reduced - if that makes sense.

What are Jump Tables and why are they relevant for gas consumption?

The entry point to the actual code execution is the run method of the EVM interpreter. This method is essentially going through the bytecode step by step and, for each opcode, looking up the opcode in a data structure known as jump table– Among other things, this table contains a reference to a Go function that is to be executed to process the instruction. More specifically, an entry in the jump table contains the following fields, which partially refer to other tables in other source code files.

In a jump table, each entry has a couple of fields, we need to have a look at constant gas and dynamic gas.

type operation struct {
    // execute is the operation function
    execute     executionFunc
    constantGas uint64
    dynamicGas  gasFunc
    // minStack tells how many stack items are required
    minStack int
    // maxStack specifies the max length the stack can have for this operation
    // to not overflow the stack.
    maxStack int

    // memorySize returns the memory size required for the operation
    memorySize memorySizeFunc

    halts   bool // indicates whether the operation should halt further execution
    jumps   bool // indicates whether the program counter should not increment
    writes  bool // determines whether this a state modifying operation
    reverts bool // determines whether the operation reverts state (implicitly halts)
    returns bool // determines whether the operations sets the return data content
}

constant gas is the constant gas value of the operation, and dynamic gas is the gas value of the operation as a function of the parameters.

Since gas is computed from opcode, the library gas usage isn’t considered - since it is computed via jump tables from opcodes. But bytecode undergoes the same linking process as the linking process of libraries in C.

What are Precompiled Contracts?

These are four so-called ‘precompiled’ contracts, meant as a preliminary piece of architecture that may later become native extensions. The four contracts in addresses 1, 2, 3 and 4 execute the elliptic curve public key recovery function, the SHA2 256-bit hash scheme, the RIPEMD 160-bit hash scheme and the identity function respectively.

Full, updated list-

Recovery of ECDSA signature
Hash function SHA256
Hash function RIPEMD160
Identity
Modular exponentiation (EIP 198)
Addition on elliptic curve alt_bn128 (EIP 196)
Scalar multiplication on elliptic curve alt_bn128 (EIP 196)
Checking a pairing equation on curve alt_bn128 (EIP 197)
BLAKE2b hash function (EIP 152)

Implemented in geth as such

var PrecompiledContractsByzantium = map[common.Address]PrecompiledContract{
    common.BytesToAddress([]byte{1}): &ecrecover{},
    common.BytesToAddress([]byte{2}): &sha256hash{},
    common.BytesToAddress([]byte{3}): &ripemd160hash{},
    common.BytesToAddress([]byte{4}): &dataCopy{},
    common.BytesToAddress([]byte{5}): &bigModExp{},
    common.BytesToAddress([]byte{6}): &bn256Add{},
    common.BytesToAddress([]byte{7}): &bn256ScalarMul{},
    common.BytesToAddress([]byte{8}): &bn256Pairing{},
}

Precompiled contracts are not native opcodes, but are calculations that are implemented in the EVM codebase for efficient calculations without EVM overheads.

Ref 👉https://ethereum.stackexchange.com/questions/440/whats-a-precompiled-contract-and-how-are-they-different-from-native-opcodes/28469

What are the pros and cons of the EVM compared to other VMs?

JVM is another popular process VM - it has it's advantages, of course, but EVM allows for finality and gas-implementation, two important factors of the Ethereum ecosystem.

From Source to Binaries: The journey of a C++ program

abhinav the builder — Thu, 15 Oct 2020 18:18:04 +0000

If you couldn't already tell, I love Bjarne, and by extension, I love C++. In this article, I go over how C++ compiles a program to binaries, and why I love C++. This is partially to understand how C++ works. Documentation helps me understand.

There are only two kinds of languages: the ones people complain about and the ones nobody uses.
― Bjarne Stroustrup, The C++ Programming Language

I got pretty inspired by HaoranWang's CRUST and thus wanted to write my own Compiler for C. I'll probably stick to Rust. Also, shoutout ShivyC, that's where I got this idea from.

Let's get started with the compilation pipeline!

What you see above is the compilation flow taken from NerdyElectronics.com.

For the purpose of this article, we will use a simple addition problem with predefined values.

//a.cpp program
#include <iostream>
using namespace std;

int main()
{
    int firstNumber = 2, secondNumber =4, sumOfTwoNumbers;

    // sum of two numbers in stored in variable sumOfTwoNumbers
    sumOfTwoNumbers = firstNumber + secondNumber;

    // Prints sum 
    cout << firstNumber << " + " <<  secondNumber << " = " << sumOfTwoNumbers;     

    return 0;
}

If you go back to the diagram, you can see we are presently on the preprocessing stage. Let's have a quick look at the Translation Unit. Translation Units is the input you give to the compiler, after it includes header files and expands macros.

You can get your Translation unit dump using the following command

g++ <filename>.cpp -E

The dump looks something like this

# 1 "a.cpp"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.cpp"
# 1 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\iostream" 1 3
# 36 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\iostream" 3

# 37 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\iostream" 3

# 1 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\mingw32\\bits\\c++config.h" 1 3
# 236 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\mingw32\\bits\\c++config.h" 3

# 236 "c:\\mingw\\lib\\gcc\\mingw32\\8.2.0\\include\\c++\\mingw32\\bits\\c++config.h" 3
namespace std
{
  typedef unsigned int size_t;
  typedef int ptrdiff_t;

It's too damn long to post here (because it literally adds stdio header file, that's like 1k lines of code), but run it on your system if you're curious.

Assembly Code

Detouring for a bit, There's this grapevine that the closer you are to the hardware, the faster you will be. While there is a modicum of truth to this, often "slower" languages like Python are slow because they're interpreted or are memory hogs due to dynamic typing. There are plenty of Python-to-C/C++ compilers and there are plenty of projects that help you do Python "faster". Don't, for the love of God, develop something in a certain language because it is "closer to the hardware".

Anyway, now run this on the a.cpp file we had

gpp a.cpp -S

Now you'll have something like this

    .file   "a.cpp"
    .text
    .section .rdata,"dr"
__ZStL19piecewise_construct:
    .space 1
.lcomm __ZStL8__ioinit,1,1
    .def    ___main;    .scl    2;  .type   32; .endef
LC0:
    .ascii " + \0"
LC1:
    .ascii " = \0"
    .text
    .globl  _main
    .def    _main;  .scl    2;  .type   32; .endef
_main:
LFB1502:
    .cfi_startproc
    leal    4(%esp), %ecx
    .cfi_def_cfa 1, 0
    andl    $-16, %esp
    pushl   -4(%ecx)
    pushl   %ebp
    .cfi_escape 0x10,0x5,0x2,0x75,0
    movl    %esp, %ebp
    pushl   %ecx
    .cfi_escape 0xf,0x3,0x75,0x7c,0x6
    subl    $36, %esp
    call    ___main
    movl    $2, -12(%ebp)
    movl    $4, -16(%ebp)
    movl    -12(%ebp), %edx
    movl    -16(%ebp), %eax
    addl    %edx, %eax
    movl    %eax, -20(%ebp)
    movl    -12(%ebp), %eax
    movl    %eax, (%esp)
    movl    $__ZSt4cout, %ecx
    call    __ZNSolsEi
    subl    $4, %esp
    movl    $LC0, 4(%esp)
    movl    %eax, (%esp)
    call    __ZStlsISt11char_

Again, too damn long, try it out on your own system! This will be built for your target architecture. Find out what is your system's architecture as an exercise! Now, Each architecture has a different Instruction Set that is understood by its processor and your compiler splits this into processes:

Create an Abstract Syntax Tree
Generate architecture dependent instructions

Let's go over what that means.

Abstract Syntax Trees

Abstract Syntax tree is well, abstract from the target architecture. However, that's not where the "abstract" part of the term comes from. According to the Wikipedia, abstract refers to the fact that "it does not refer to every detail appearing in the real syntax, but rather just structural or content related details". ASTs are generated after syntax analysis. All programs can generate an AST. For our code, this is what the AST looks like

Here's how to do it yourself

g++ -fdump-tree-all-graph a.cpp -o a
dot -Tpng a.cpp.013t.cfg.dot -o a.png

This is built using GraphViz, install it for your command line. You can also copy paste the contents of a.cpp.013t.cfg.dot on any online GraphViz visualizer.

Object File and Linking

Object File has object code, that is essentially machine code (or some intermediate code). It is the "object" of compiling process, as you can see in this classic article. The reason I didn't use that fancy "Phases of Compiling Process" chart is because it kind of abstracts the real process of compilation. In due time, we will talk about that too. Create your object (.o) file using this, before we go ahead.

g++ a.cpp -c

Now, let's look at linking, which you do after you create your object files. The object files are linked together to create another object file that is executable. For this, let me divide the program into a header and a main CPP file.

//a.h
#include <stdio.h>
void printLinker()
{
    printf("Hello World");
}

Now, let's call that in another file

#include "a.h"
int main()
{
    printLinker();
    return 0;
}

Finally, to show the linking, let's create another source file

//We will name this a2.cpp
void printLinker();

Compiling a.cpp would give me a Hello World, as expected. But we need to see the linking, right?

g++ a.h -c
g++ a.cpp -c
g++ a2.cpp -c

Now, we are back to having a .obj and a .gch (precompiled header, if this is not found, the compiler looks for the header). Let's link!

gcc a.o a2.o -o a2.exe

Nice, you see how we just called the two object files and compiled them? Now we need to just run a2.exe, it would have printed Hello World.

./a2.exe
Hello World

Perfect. If you want to see what lies inside these files, you use nm tool.

nm a.o

You get the following

00000000 b .bss
00000000 d .data
00000000 r .eh_frame
         U ___main
00000015 T _main
         U _printf
00000000 r .rdata
00000000 r .rdata$zzz
00000000 t .text
00000000 T __Z7print_av

You can do the same for the other object file! It is pretty clear what the files contain, it is well sectioned.

Whew, that was a lot, that's how a compiler compiles. Let me just conclude real quick.

Preprocessing
Compilation
Assembly
Linking

That's about it, folks! See you around in part 2, which I will update here.

Gameboy: Everything under the hood.

abhinav the builder — Mon, 12 Oct 2020 10:53:11 +0000

I don't like consumerism. One of my favorite Scholars, Bertrand Russell, once said

"It is preoccupation with possessions, more than anything else, that prevents us from living freely and nobly."

But you can bet I have a soft spot in my heart for Nintendo products. Pokemon on Game Boy Advance was one the only games I have ever truly enjoyed before being dragged by the dark, drab realities of life. I'd love to have a shelf with Pokemon merch, but I digress.

Now that we are done with that segment, let's get started by looking at the beautiful, beautiful Game Boy Classic!

The Game Boy is as old as me, and it has more processing power than me. It has an 8-bit processor called the SHARP LR35902, which is a "hybrid" between Intel 8080 and Zilog Z80. Z80 is considered an enhancement of the 8080. Z80 had an enhanced instruction set that had single-bit addressing, shifts/rotates on memory and registers other than accumulator. You had program looping, program counter relative jumps, block I/O and byte search instructions. Z80 also had new IX and IY index registers and a better interrupt system. SHARP LR3590 had a little bit of both.

8080's registers are used (Single Register file)
Z80's Coding Syntax and Instruction Extender was used.
However, neither IX, IY nor 8080's I/O scheme were used. SHARP used a completely memory scheme, so these were not needed.
Like 8080, a 8-bit data bus and 16-bit address were used, where a memory of 64 KB of Memory could be addressed.
The memory map had: Cartridge ROM, WRAM, Display RAM, I/O and interrupt enabler.

We had a clock speed of about 4.2 MHz, which is achieved by a Crystal Oscillator. All of this worked on 3V DC, 0.6W supply.

(That's CPU + Power Processing Unit + Audio Processing Unit)

Gameboy's 8-bit CPU is called DMG CPU, equipped with 6 registers of 16 bit each: AF, BC, DE, HL, SP and PC. Here's what they mean -

AF: AF are two 8-bit registers, A and F. A is the Accumulator (arithmetic operations usually take place here)

If you dial back to your Microcontrollers class, this is the Von Neumann Architecture and there is the accumulator
F is the Flag Register, it's a special purpose register where each of the 8-bit have different purposes.
- Zero Flag (Z): This bit is set when the result of a math operation is zero or two values match when using the CP (call If Positive) instruction.
- Subtract Flag (N): This bit is set if a subtraction was performed in the last math instruction.
- Half Carry Flag (H): This bit is set if a carry occurred from the lower nibble in the last math operation.
- Carry Flag (C): This bit is set if a carry occurred from the last math operation or if register A is the smaller value when executing the CP instruction.
BC, HL, DE are General Purpose Registers. They're used for 16-bit operations such as temporary storage, copy during execution of the program. Mostly memory stuff.
PC is the program counter, which points to the next instruction in the memory. The CPU uses PC to fetch the next operation that needs to be executed.
SP is the Stack Pointer, which points to the current stack position in the memory. This can get a little hairy, grab your closest notebook if it gets overwhelming. With a fair bit of Googling, if you've followed the article thus far, I'm sure you know what a Stack is.

The stack in GameBoy usually keeps the variables and return addresses. It is also used to pass arguments to subroutines. So, to push information to the stack you would use PUSH, CALL and RST instructions. POP, RET and RETI are used to take information off the stack. The GameBoy stack pointer (SP) is used to keep track of the top of Stack. Remember, the Stack is a first-in, first-out data structure, so the top of the Stack will be the most recent data.

Now in GameBoy, execution starts at location 0, which is where GameBoy's boot ROM is located. You'll find the first instruction for the cartridges at the location 0000000100000000 , and we'll talk more about this in a minute.

A typical way to fetch the instruction from memory would look like this charming little self-explanatory pseudocode.



1. variable program_Counter = 0x0100 
2. variable operation = fetch_Operation(PC)
3. switch(operation){ case no_Operation{break}; case operation{operation; break;}

//The fetch_Operation would be
define operation{return memory[program_Counter++]

Now, remember, Z80 and GB's CPU use syntactically similar languages, so when we look at some real GB codes, don't be too surprised to discover that Z80 and LR35902 have similar looking codes. For example, the instruction extender is same in both (opcode 0xcb).

An important note on commands

Alright, now that these commands have been fetched, we need to execute these commands. There are 8-bit load commands and 16-bit load commands. They do the work of loading things from place A to place B (eg. loading the content of a register to a stack). Finally, there are 8-bit Arithmetical and Logical Operations (eg. increment a value stored in register). In the DMG CPU, there's not a lot of 16-bit arithmetical operations to start with, and they just operate on the 16-bit registers. There's also shifting and rotation (shifting but the bits wrap around the edges) commands (eg. 00010000 -> 00100000).

There are a few couple other control operations as well: HALT (Halt until interrupt), NOP (Don't do anything), Enable/Disable Interrupts. Then you've got Jump operations, using which you can jump to any location in the memory.

Let's talk about memory

Data is a bit obscure to the CPU. All this hullabaloo of wires we deal with in real world is irrelevant to the CPU. It is a processing unit, it gets data and it processes it. CPUs process all data, some correctly, some wrongly, but it is a heartless, agnostic machine, that takes in data, churns out data.

Address Bus is that good friend of the CPU that delivers it just that: Data. Address Bus are Read/Write lines that are used to transfer data.

Address Bus is also everyone else's friend! The peripherals and cartridge are all on the address bus! Let's dig a little bit deeper now.

Memory and Memory-Mapped I/O

Memory Mapped I/Os (MMIO) tend to share the memory space with the external memory. MMIO are just methods of connecting the CPU and the peripheries.

What you see above is the general memory map of GameBoy, that I took from here. They write in depth about GameBoy and I've used their article among others (linked below) to research for this article, shout out!

We will be looking specifically at ROM and Switchable ROM bank, which are the first two regions of the memory.



  0000-3FFF   16KB ROM Bank 00     (in cartridge, fixed at bank 00)
  4000-7FFF   16KB ROM Bank 01..NN (in cartridge, switchable bank number)
  8000-9FFF   8KB Video RAM (VRAM) (switchable bank 0-1 in CGB Mode)
  A000-BFFF   8KB External RAM     (in cartridge, switchable bank, if any)
  C000-CFFF   4KB Work RAM Bank 0 (WRAM)
  D000-DFFF   4KB Work RAM Bank 1 (WRAM)  (switchable bank 1-7 in CGB Mode)
  E000-FDFF   Same as C000-DDFF (ECHO)    (typically not used)
  FE00-FE9F   Sprite Attribute Table (OAM)
  FEA0-FEFF   Not Usable
  FF00-FF7F   I/O Ports
  FF80-FFFE   High RAM (HRAM)
  FFFF        Interrupt Enable Register

The memory you see at 0100-014F is the internal information area. It has the Nintendo Logo, from here the entry point is established, the boot procedure then jumps to the main cartridge program. Now there are other metadata codes and flags that we will skip right now.

Now that's all about the CPU of the GameBoy. I dug a little into how cartridges work, but nothing too much in depth. One day when I understand the cartridge system, I'll be back here!

To read more about display in GameBoy, refer to Rodrigo's blogs here. A lot of the research for the article, was done by reading Raphael's GameBoy building Series, which you can read here. Of course, with this I leave you with my other two favorite resources, Game Boy CPU Manual and Pan Doc's Everything You Always Wanted To Know About GameBoy.

If you enjoyed reading the article, show some love with those funky like buttons. Let me know where could I improve, or if you have any questions. I'll be doing more such "Under the Hood" articles inspired by Rodrigo, so stick around!

Abhinavmir, signing off.

Credits for images:
[1] http://meseec.ce.rit.edu/551-projects/spring2014/4-1.pdf
[2] https://www.quora.com/What-is-an-accumulator-in-computer-science
[3] GameBoy CPU Manual
[4] FreeCode Camp on Stacks
[5] Raphael's Building GameBoy article

Bitcoin and the claim of Total Turingness.

abhinav the builder — Thu, 08 Oct 2020 06:25:57 +0000

Craig Wright is a very controversial man — Bitcoin SV, Claims of being Satoshi Nakamoto, major plagiarism accusations- Overall, not the face of Blockchain you'd want. But Craig Wright is also a very smart man, much more than the Twitter handles in the Crypto Community would have you believe. His degrees and years of experience are something you cannot ignore, or at least that's what the BSV community and Wright himself want you to believe.

We give Dr. Wright the benefit of doubt today. In 2014, Dr. Wright came out with a paper titled “Bitcoin: A total Turing machine” [1] and today we talk will about it.

If you don’t know about Turing Machines, now is a good time to talk about it. Turing machines are theoretical models of computation that represent an abstract machine. Turing machines are tapes divided into cells.

A Universal Turing Machine

Turing machine was put forth by the legendary Alan Turing in ’36 and it proved something very important: the uncomputability of the Entscheidungsproblem. Turing Machines cannot be implemented in real life of course, because we don’t have infinite tapes in real life, and because these machines aren’t optimized for real-life implementations. For example. Real Life computers use RAMs, which TMs don’t. But TMs can compute anything a real computer can, given duration of computation is not an issue.

Turing Completeness is the idea that any program that is Turing Complete will halt. And any program that halts will not tend to infinity. From here we deduce that a Turing Machine should run infinite time.
How does this all relate to Bitcoin?

Bitcoin’s Script is a stack-based, non-Turing Complete programming language. And there is a lot of conversation about this, especially attacking the Ethereum community for being Turing complete, and the lack of need to be Turing complete because “Post’s theorem”.

Representation of a Stack Data Structure

Post’s theorem posits the connection between Arithmetical Hierarchy and Turing degrees [2]. It is often stated defending the lack of need of Turing Completeness, and safety of decidability as another.

Wright proposes Bitcoin has been what he proposes to call a “Probabilistic Total Turing machine”. Let me try to summarize Craig’s claims

Wright proposes that Bitcoin is equivalent to the machine proposed in Wolfram’s conjecture, which states that a 2 state, 3 symbol Turing Machine is a Universal Turing Machine. By this, a proposition establishes that Bitcoin Script must also be a Universal Turing Script.
Wright states that Bitcoin is Turing Complete and proves so using the Ackermann functions.

Wright proposes that Bitcoin Script is a Probabilistic Total Turing Machine, which is something he proposes earlier. PTTM is different from PTMs. The alternate stack in the Script makes it Turing Complete.
Lack of looping in Bitcoin Script does not it non-Turing Incomplete. Since Bitcoin is formed using Primitive Recursion Functions, the script construct is Turing Complete.

Let’s try to dissect all this. Bitcoin does not support loops: This by itself does not make the script Turing Complete or Incomplete, but this does mean that the script lacks Control Structures. Sure, if-else is there, but without For loops, there is a lack of Control. This is not a bug in the language, it is a feature. A small script such as Busy Beaver [3] will cause the Bitcoin network to return DoS overtime at worst, and slow down the hash rate at best. This was implemented to increase decidability and safety.

Two stacks don’t make a Turing Complete Machine: To Simulate a Two-Stack PDA (Which is Turing complete), you need a control structure. As I said in, Bitcoin lacks For loops.
Bitcoin limits the number of non-Push operations you can do per script: If you look at Bitcoin’s Github, you will see the following piece of code

static const int MAX_OPS_PER_SCRIPT = 201;

This means that you can do 201 non-Push ops per script. This is to safeguard against undecidable problems. So even if you implemented a 2PDA, you would be practically limited by this.
Whether or not Bitcoin is Turing Complete is a futile discussion. Bitcoin Network is “more” Turing than other networks because of its size (That statement holds no scientific value, I said it as a figure of speech). Bitcoin Script is better off Turing incomplete by design, even though there might be some “proof” of it being otherwise. P2P consensus networks need to implement some form of decidability in their scripts. Ethereum, for example, has a Gas-system. It’s quasi-Turing Complete for that reason. Bitcoin Script, if used outside of the Bitcoin network, would have issues because it is Turing Incomplete by design, but a few modifications, and you can build it to be Turing Complete. But in practicality, no system is truly Turing Complete. I would love your comments about this!

Further Reading
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3265146
[2] https://youtu.be/TGE6jrVmt_I
[3] https://en.wikipedia.org/wiki/Busy_beaver

Deno: Everything you need to know.

abhinav the builder — Mon, 18 May 2020 17:27:23 +0000

In 2018, Ryan Dahl gave a talk titled "10 things I regret about Node.JS" - and at the end he introduced a new runtime called Deno. Before we get into Deno, let's talk about why Ryan might have wanted a new runtime in the first place.

What Node lacked

In the talk, Ryan went over a few regrets he had with the Node ecosystem, and I love how he addressed all of it because with time, technologies change - And in the case of Node, the ecosystem around it had changed drastically. Deno solves a few important issues that Node has, and this is how.

Node has access to essential System Calls

Node Programs can write to Filesystems and related networks because in the original Node, which was built in C++ by building a wrapper (of sorts) around V8 engine, had skipped some important security functions. This, I imagine is because V8 is a secure, solid sandbox, but it is to be used inside of Chrome (or whatever other browsers implement it), but Node can be used as a CLI tool. Node files could have access to a lot of essential system calls and they could, and have resulted in malicious behavior.

crossenv malware on the npm registry
(https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry)

The devs dropping out Promises

Node was designed before JS introduced the concept of Promises or Async/Await. Node instead found a way around promises with EventEmitters, and a lot of APIs are built around this - Sockets and HTTP for example. Async/Await is amazing when you consider how ergonomically handy it is to use. Emitters caused a lack of well-defined protocols to deal with backpressures in streams. While this was okay for some streams, in other cases it causes a buildup, like when the receiving process is slower than sending - eg TCP, MQTT. File read/write (Write is slower than Read). In modern JavaScript, Promises provide the delegation in the form of abstraction, but Node did not have this for its own APIs - and much newer Async APIs are becoming less compatible over time.

Node Package Manager is clunky

Package.JSON is a handy, nifty little file that helps you install your NPM packages on a new system in a quick function - But package.JSON has its own problems.
Package.JSON aimed to create a local machine of sorts for Node in a folder, but it took a lot of time, was heavy, and usually ran into problems out the box. Package.JSON is also very cluttered with metadata.

Deno does not have a package manager! Deno relies on URLs to host and import packages, which I am assuming will be through a CDN, thus we can take advantage of caching! Some people in the Deno community are also trying to have a Go-like dependency handling: Compiling the program into an executable that you can run without external dependencies - But it's not a thing yet.

The Node Build System hasn't aged well

Node uses GYP Build System, which is very complicated and somewhat broken. You can read a comparison of GYP to CMake Here -
https://gyp.gsrc.io/docs/GypVsCMake.md

cMake is essentially a Unix system tool, and it is not cross-platform: Thus GYP made sense at the time. But even Chromium moved from GYP to GN, another build system which was 20x faster for Chromium's use case. This is one of Dahl's biggest regret. Node is one of the only remaining GYP users.

Out of the box TypeScript Support

TypeScript is amazing - Optionally static typing and Type interfaces are two of the best things about TypeScript. But setting up TS with Node is a pain: You need to install dependencies, you need to configure your tsconfig.json, you have to update package.json - It's all too much. With deno, it's out of the box, no additional tooling required.

Explicit is better than implicit

For example, no .JS tags while importing a module!
It is one of my biggest problems with Node, and Ryan mentioned that as well. It is needlessly less explicit. It is also unnatural: Browsers need you to have.JS extensions. I can understand where this came from, but we can also see how it is broken.

Is Node really dead?

No, I was being sensationalist. Node will be alive for years to come since a lot of websites are securely built in Node, it is awesome and has a strong community around it. Small-time projects might see a shift to Deno - Personally, I have a Supply Chain project where I might use Deno.
It is less clunky, lighter, more intuitive, and explicit. I also love how it uses Rust Crates and is not a monolith. I am not sure if Node was, but I think it was a monolith that directly called C++ APIs.

function hello(place: string): string { return `Hello ${place}`} console.log(hello('world'))

That is a simple 'hello world!' that runs like this

./deno hello.ts

Hello world

And a simple URL import would be

import { factorial } from "https://gist.githubusercontent.com/DanielRamosAcosta/ad514503b1c7cf8290dadb96a5fddee9/raw/4733e267f05d20110ba962c4418bab5e98abfe93/factorial.ts" 
console.log(factorial(10))

This is beautiful, don't you think?

🌺 Hey, I hope you enjoyed reading that article. I am Abhinav, editor @ The Crypto Element. It takes a lot of work to research for and write such an article, and a clap or a follow 👏 from you means the entire world 🌍 to me. It takes less than 10 seconds for you, and it helps me with reach! You can also ask me any questions, or point out anything, or just drop a "Hey" 👇 down there. I 💓making new friends!

Developing React Apps by Consuming APIs

abhinav the builder — Wed, 01 Jan 2020 17:16:44 +0000

In the previous part, I talked about developing the backend with a GUI, you can serve your database as an API. Few benefits:

AJAX-style loading, because page reloading is not needed.
Hosting on two different servers is a lot more secure. It takes a little work to figure out where the admin panel is, otherwise it’s just website.com/admin. Now website.com serves the frontend, fetching APIs from a backend you know the URL of.
Super customizable.
Faster, since all your code is not hosted on one server.
If something breaks, you know where to dig in first.

Enough talk, let’s get coding. To be fair, this can be done without React. To also be fair, you can dig a pool using spoons. You don’t, right? I’ll explain how React works as we code, just keep in mind what we are doing: Fetching an API and displaying it but in style.

First, start your project with

npx create-react-app strapireactcscd strapireactcsyarn start

I used the file name ‘strapireactcs’ because I want to make a differentiation that this is a CS- or Client-Side Code. This is purely for convenience.

One more thing, make a parent directory for the Strapi backend and React frontend. It should look like this-

parentdir
|__strapireact
|__strapireactcs

This is a good practice.

Now, let’s look at our project structure. You should have two subfolders named *Public *and *Src. *Heads up, we will be using Materialize CSS to style our app, so go ahead and add the CDN to index.html.

Add this how you would to a normal HTML file.

<!-- Compiled and minified CSS --><link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css"><!-- Compiled and minified JavaScript --><script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"></script>

This will be in index.html, which is where we will call* app.js.*

Now let’s head over to app.js!

import React from 'react';

We have to have React in our JavaScript file to use it!

Declare the class

export default class People extends React.Component{

The logic for our app goes into this. First we declare a state.

state={people:[]};

According to W3:

React components has a built-in state object.The state object is where you store property values that belongs to the component.When the state object changes, the component re-renders.

React components has a built-in state object.

The state object is where you store property values that belongs to the component.

When the state object changes, the component re-renders.

*people *will be where the JSON data will be stored that we will get from the server.

async componentDidMount(){  const url="http://localhost:1337/todos";  const response=await fetch(url);  const data=await response.json();  console.log(data);  this.setState({todo:data});}

ComponentDidMount() is a function of React that runs the content inside the parenthesis after the page markdown has loaded.

It’s a good place to setState, that is- Set a value to the state object.

When I console.log’d data, you should be able to see an object in your inspect element console (CTRL+SHIFT+I on Windows).

Let’s Render some HTML now?

Render() function serves the HTML to browser. You can write JavaScript in {} and React will take the value and turn it to HTML Hypertext.

render() {  const mystyle={padding:'10px'}return ( <div style={mystyle}>     {this.state.todo.map(todo=>(     <div class="card" style={mystyle}>         <div>{todo.title}<br></br>{todo.deadline}<br></br></div>     </div>))}</div>);}}

Now during deployment, you will just have to replace localhost URI with the URI of your backend server. Map is an iterative function. Dot is used to access data members of an object.

So for example, todo.deadline is used to access deadline data from todo state object.

So here is the original API fetch request would give us-

And after fetching that data and serving it with React, we get

Next we will talk about deployment to Heroku, you can also find the Github there.

Bitcoin and the claim of Total Turingness.

abhinav the builder — Sun, 29 Dec 2019 20:32:24 +0000

We give Dr. Wright the benefit of doubt today. In 2014, Dr. Wright came out with a paper titled “Bitcoin: A total Turing machine” [1] and today we talk will about it.

A Universal Turing Machine

Representation of a Stack Data Structure

Wright proposes Bitcoin has been what he proposes to call a “Probabilistic Total Turing machine”. Let me try to summarize Craig’s claims

Wright proposes that Bitcoin is equivalent to the machine proposed in Wolfram’s conjecture, which states that a 2 state, 3 symbol Turing Machine is a Universal Turing Machine. By this, a proposition establishes that Bitcoin Script must also be a Universal Turing Script.
Wright states that Bitcoin is Turing Complete and proves so using the Ackermann functions.

static const int MAX_OPS_PER_SCRIPT = 201;

Further Reading
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3265146
[2] https://youtu.be/TGE6jrVmt_I
[3] https://en.wikipedia.org/wiki/Busy_beaver

Developing the simplest blockchain using Vanilla JavaScript

abhinav the builder — Wed, 25 Dec 2019 05:10:39 +0000

Understand the basics.

Pre-requisites: Some rudimentary knowledge of OOPs in JavaScript.

We are using Node for this exercise. You could use Python or Go for the same, but I am using this since I am going to show you how to integrate this with your Node app. I take heavy inspiration from Savjee, I am using his series on blockchain as inspiration and putting my best understanding out there.

If you don't have Node, feel free to install it from your favorite package manager or the internet. A little bit about Node first: Node is JavaScript outside of your browser. You don't need script tags to run this JS, all you need to do is-

node filename.js

This is because some madlad took Chrome's V8 engine out of Chrome and wrapped it in C and served us Node. Talk about *Jugaad.*

The first thing you'll need to do is make a new directory and CD into that. Then you need to init an NPM package, and create an index.js file.

mkdir blockchain-example
cd blockchain-example
npm init -y
vi index.js

I am using Vim because I am terribly lazy, feel free to use any text editor of choice. Now let's talk a little bit about what a blockchain is before we delve further into code. The best explanation I have read is this article by IHODL.

To quote from their website-

Blockchain is a distributed database existing on multiple computers at the same time. It is constantly growing as new sets of recordings or blocks, are added to it.

Each block contains a timestamp and a link to the previous block, so they actually form a chain.

The database is not managed by any particular body; instead, everyone in the network gets a copy of the whole database.

All blocks are encrypted in a special way, so everyone can have access to all the information but only a user who owns a special cryptographic key is able to add a new record to a particular chain.

In addition, cryptography is used to guarantee synchronization of copies of the blockchain on each computer (or node) in the network.

Read more at their website.

https://www.researchgate.net/figure/Simple-example-of-blockchain-technology_fig4_325486515

Look at the diagram above. All transactions are stored in Blocks, so every one knows what data is being transacted. Now before you are up in arms about security, this data is not open for everyone to see (It is in very few cases!). They are hashed, as we will see. You can only verify this transaction, verifying means that they can't be tampered with. For simplicity, these transactions are shown as currency here, but they could be any data.

Let's jump into code and from there explain a little here and there?

const sha256 = require('sha256'); 

class Block {  
constructor(index, timestamp, data, prevHash) {    
this.index = index;    
this.timestamp = timestamp;    
this.data = data;    
this.prevHash = prevHash;    
this.thisHash = sha256(      this.index + this.timestamp + this.data + this.prevHash    );  
}}

Do you understand what happened? We made a goddamn block. This is the fundamental logic behind every blockchain unicorn founder that got rich. Pay attention.

First, we import SHA256, it's an encryption algorithm. As I said, it's to encrypt the data.

The class BLOCK is a block template we will use for every block.

Each block will have five elements: index, timestamp, data, Previous Hash and Present Hash.

For CryptoCurrencies (esp the earlier ones like Bitcoin), the data is the address of the sender, receiver of bitcoin and amount of Bitcoin transacted.

Now that you know what One block looks like, I am sure you have a better understanding. Let's move on to what would we do about the first block, right? Since our first block has no Previous Hash!

We create something called the Genesis Block.

All of this will come under a class called blockChain.

const createGenesisBlock = () => new Block(0, Date.now(), 'Genesis Block', '0');

What it do? Simple. Create an instance of the class with 0 as the index, present date as date, 'Genesis Block' as data (You can keep this as anything as long as you remember what your initial block is named) and 0 as the previous hash.

We will need two functions: getLatestBlock() and calculateHash().

getLatestBlock() {
return this.chain[this.chain.length - 1];}

calculateHash() {
return SHA256(this.index + this.previousHash + this.timestamp + JSON.stringify(this.data)).toString();}

getLatestBlock() fetches the latest block from the chain. Out of context it might be confusing, check the GitHub, you'll get a better understanding.

calculateHash() calculates the Hash, we have talked about this before.

Now let's create an addBlock function.

addBlock(*newBlock*) {
newBlock.previousHash = this.getLatestBlock().hash;
newBlock.hash = newBlock.calculateHash();
this.chain.push(newBlock);
}

This function takes in a parameter called newBlock, which is basically the block we will be adding. To use this function we will run it something like this:

let bkc_app=new blockChain();
bkc_app.addBlock(new Block(index, Date(), data))

Now addBlock will take that block we need to add as parameter, add a previousHash to it by getting the hash of the latestBlock, adds a present Hash to it by doing a calculateHash() on it and pushes it to the chain.

Yay, the simplest blockchain in the world is now ready!

Let's take it for a spin.

let bkc_app= new Blockchain();

data = {
'story':'Quick Brown Fox'
}

bkc_app.addBlock(new Block(1, Date(), data))

console.log(bkc_app, JSON.stringify(khbr, null, 4))

Check the final results here.

We created a very basic blockchain. In the next few tutorials I will talk about Bitcoins, Ethereums, Cosmos/Matic, Hyperledger and concepts like Proof of Work and Proof of Stake. Stay tuned, give me a follow and clap if you enjoyed.

Signing Off,

Abhinav Srivastava.