Richard Kiss richardkiss

Generator Identity and Cost Hard Fork: Complete Summary

This document provides a comprehensive overview of the hard fork that transitions generator identity and cost calculation from serialization-based to content-addressable (tree-structure-based) methods.

Executive Summary

This hard fork makes two fundamental changes to how generators are identified and charged:

Identity: Generator identity changes from SHA256(serialized_bytes) to SHA256_tree_hash(generator) (content-addressable)
Cost: Generator cost changes from len(serialized_bytes) × 12000 to a blended formula based on interned tree structure

RocksDB Storage Migration Plan

Overview

We are modifying the chia-blockchain project to allow RocksDB to be optionally used instead of an SQLite database. RocksDB's LSM-tree structure improves upon the SQLite B-tree performance degradation we observe as the coin database grows larger.

TLDR

prototype suggests RocksDB can be used for consensus-critical data with a simple schema and a simple API using just write batches rather than full transactions
encapsulation of DBWrapper2 in SQLite3-based storage wrappers

Understanding CLVM Compression

Introduction

CLVM compression was designed for straightforward implementation within CLVM itself. To understand how it works, we'll first examine the standard deserialization algorithm implemented in CLVM. See also here https://github.com/Chia-Network/clvm_rs/blob/7e58298b85aed07672678e54b9f28571724814dd/cl/deserialize_w_backrefs.cl

Basic Concepts: CLVM Stack Operations

A CLVM stack is a nil-terminated list of CLVM objects. Stack operations push and pop from the front:

Push operation: (c new_object old_stack)
Pop operation: (f stack) returns topmost object

This is a report on the chia-blockchain sqlite3 DB. The concern is that some operations are slow, and get slower over time. The symptom is the conversion from v1 of the DB to v2 never finishes and seems to get slower asymptotically as time goes on. This may affect performance during regular day-to-day operation, since DB conversion is not wholy different from DB operations performed on a day-to-day basis.

Summary

There are six tables and eight indices.

The load_clvm method has been duplicated in multiple places, each version with slightly different semantics and bugs. We present here a set of tiny python wheels that solve many problems with chialisp contracts including:

distribution of libraries
distribution of compiled .hex files
automatic dynamic builds in development mode
dependency analysis (on library include files)

`runtime_builder`

Add the non-free debian repository

echo 'deb http://ftp.us.debian.org/debian bullseye non-free' > /etc/apt/sources.list.d/non-free.list

Refresh

apt update

Add proxmox-specific headers required for DKMS https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

	#!/usr/bin/env python3
	"""
	Systematic import detector using is-comparison to find true import sources.
	Clean algorithm: try all potential import locations, use 'is' to find the truth.
	"""

	import inspect
	import importlib
	from typing import Dict, Set, List, Optional, get_type_hints, get_origin, get_args

	from ctypes import CFUNCTYPE, c_int


	Ft = CFUNCTYPE(c_int, c_int, c_int)


	def entry_point(ptr_to_function):
	function_pointer = Ft(ptr_to_function)
	result = function_pointer(5000, 2)
	return result

	from math import comb
	from typing import List


	Hand = List[int]


	def hand_from_index(index: int, deck_indices: List[int], hand_size: int) -> Hand:
	hand = []
	deck_size = len(deck_indices)

	(mod V0 ;; V0 should be 0

	(include standard-cl-21)

	;; projective point: ((X . Y) . Z)

	(defun-inline x-for-p (POINT) (f (f POINT)))
	(defun-inline y-for-p (POINT) (r (f POINT)))
	(defun-inline z-for-p (POINT) (r POINT))