Skip to content

Instantly share code, notes, and snippets.

@Earlz
Earlz / personal-ann.md
Created September 4, 2021 01:27
A personal announcement

As a preface, I am currently on a sabbatical year from Qtum. Basically I figured all this stuff out and decided to take a break from working to focus on my own mental health and to figure myself out. I was not forced out of Qtum and did not leave because of any discomfort there.

A summary of this huge post: I’m a woman and I’m transitioning so that I look and feel how I've always seen myself. I go by the pronouns she/her but they/them is cool too. The name Jordan is completely fine with me, but I’m considering also going by Ashley and have been testing that out. Don’t call me “Earlz” (yes I'm fully aware past me was dumb and made a million different accounts named "earlz"). I’ve had signs of being trans all my life. It’s a realization and not a choice I made. I “cracked” and accepted it several months ago. My sexuality is kinda unknown in the confusion of gender envy right now, but I love my partner Haley and they love me. Haley has been very happy and excited about the changes I’ve been experiencing. Any su

@Earlz
Earlz / sccs.md
Last active March 22, 2020 23:00

Neutron SCCS

The SCCS is a stack data structure which serves as the sole non-permanent method for communication between the smart contract VMs and the backing blockchain. It is also used for communication between different types or instances of smart contract VMs. This includes for instance calling a WASM smart contract from an x86 smart contract and sending/recieiving data between the two smart contracts. The following can be considered templates of how the SCCS looks in different scenarios when the VM begins execution

Note in all of these the bottom of the template is the first item to be popped off.

Call smart contract from TX

  • argument 3
  • argument 2
#include <qtum.h>
#include <stdlib.h>
#include <string.h>
//dumb ABI
//sends specified amount from msg.sender balance to address
#define CONTRACT_SEND 1
//returns the balance held by the specified address
#define CONTRACT_BALANCE 0
//returns balance of getSender()

The contract communication stack shall have the following items pushed onto it (in this order) upon contract termination:

  • Rest of stack (ie, the stack is not necessarily cleared and multiple items may be present)
  • User defined contract exit data (optional. Only present if smart contract code does the push)
  • Gas used, uint64_t (pushed by Qtum)
  • Contract error code (pushed by Qtum)

SCCS ABI Proposal:

Before the termination of a contract, the stack should be cleared of any items that the contract does not wish to return to the calling contract. Each contract should specify their own protocol for what data shall be returned from their contract.

Qtum x86 Trusted Library Mode

A mode exists called Trusted Library Mode. Calling a contract that uses this mode from another contract requires an explicit "allow" option because of the abilities given to the library code. This supports similar use cases as EVM's delegate-call function, but with more control by the calling contract.

Trusted Library mode is designed to be ideal for helper code and computations.

Execution Differences

When executing (and writing) trusted library code, a different memory model is used. Basically, all of the calling contract memory is "mounted" into the bottom 2Gb of the address space. Basically, all of the standard expected memory space for execution is moved up to address 0x80000000. This means when compiling Trusted Library code, care must be taken to ensure that the program is aware it will be executed at this address. Memory allocation is allowed in trusted library execution, but can only be located in the special memory allocation area. This is to prevent potential

//compiles to 2820 bytes unoptimized, 1524 optimized
//using remix version "soljson-v0.4.18+commit.9cf6e910.js"
pragma solidity ^0.4.15;
contract BrainFucker{
function interpret(bytes s, bytes1[128] input) public returns (bytes1[128] output) {
uint256 ptr=0;
uint256 i=0;
uint256 right = s.length;
//compiles to 740 bytes using -O0, 384 bytes using -Os
//both targeting i386 and with freestanding GCC compiler
typedef unsigned int size_t;
void interpret(volatile char* s, int s_size, volatile char* input, volatile char* output){
int i=0;

foo

bar

  1. foo
  2. bar
  3. baz
  4. biz
Testing 123 code
@Earlz
Earlz / greeter.c
Last active June 12, 2018 16:12
Using a Qtum prototype implementation including an x86 VM, I built this contract. It's messy cause there is not yet a standard library due to it requiring freestanding code. Compare to the Solidity implementation at https://www.ethereum.org/greeter
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef unsigned char uint8_t;
typedef unsigned int size_t;
//#include <stdint.h>
// copy-paste some library functions until we get a basic libc working
void* memcpy(void* restrict dstptr, const void* restrict srcptr, size_t size) {
use std::io;
use std::io::File;
use std::os;
use std::str;
fn main() {
println!("meh");
let filename=&os::args()[1];
let contents: String = match File::open(&Path::new(filename)).read_to_end() {
Ok(s) => str::from_utf8(s.as_slice()).expect("this shouldn't happen").to_string(),