Ash Earlz Earlz

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

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.

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

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

	#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()