Token engineering presentation 5 13-18

Token Engineering
Fundamentals
An Introduction to Information Systems Engineering
Token Engineering Meetup
May 13, 2018

Goals
• Understand Engineering Math ‘Tools’
• Understanding of the design process
• Methodologies used in development
• Tools to evaluate results

Michael Zargham
• Actively Researching Blockchain enabled
Coordination and Decision Systems
• Contributor & Advisor, Sweetbridge
• Former Director of Data Science and Architect of
Data & Decision Systems at Cross MediaWorks
• PhD in Systems Engineering, UPENN
• Research Ares: Decentralized Optimization,
Decision Science, Operations Management
• Academic expertise in optimal and stochastic
Control Theory, Game Theory & Applied Math
• Quantitative Analyst and Decision Systems
Engineer since 2005.
• Research engineer and data scientist at
BlockScience, specializing in systems engineering
crypto-economic environments. He has developed,
simulated, and tested token mechanics for smart
contracts on the blockchain.
• Advisory board on AeroChain and Fr8 Network
• Directed model test programs for US and foreign
navies.
• Master’s degree from MIT in Ocean Systems
Management
Matthew Barlin

Preliminaries
• Definition of a Network
• Definition of a Blockchain Network
• Important Token Distinctions
• Coordination Problem
• Feedback

Definition of a Blockchain Network

Generalizing Crypto-Assets
Fungible Unique
Divisible Cryptocurrencies
Equity or Shares
in specific Assets
Discrete
Tokens representing
physical Commodities
Tokens representing
Titles or Deeds
• Tokens are digital representations of Assets which may or many not be tangible (goods vs rights)
• Ownership in the asset is governed by a decentralized ledger
• Crypto-Assets allow ownership to be transferred via smart contract

States in the “Economic Network”
•Smart Contracts and non-asset states
•automate the execution of workflows defined in legal contracts (discrete states)
•maintain account balances and other dynamic values (continuous states)
•Enforce the set of legal state transitions for all types of states
•Economic Systems Have “configuration spaces” implied by their initial state and the valid state transitions
•Curse of dimensionality
•Bitcoin example – low dimension space restrictions
https://www.cs.cmu.edu/~motionplanning/lecture/Chap3-Config-Space_howie.pdf
http://web.eecs.umich.edu/~ocj/courses/autorob/autorob_14_configuration_spaces.pdf

Economic System Layer is Dynamical
https://ocw.mit.edu/courses/electrical-engineering-and-
computer-science/6-241j-dynamic-systems-and-control-spring-
2011/readings/MIT6_241JS11_chap10.pdf

Economic System Layer is Discrete
https://web.stanford.edu/class/archive/ee/ee392m/ee392m.1
056/Lecture9_ModelSim.pdf
Finite State Machine for
TCP/IP

Economic System Layer is a Hybrid System
http://www-
inst.cs.berkeley.edu/~ee291e/sp09/ha
ndouts/book.pdf
Math example for a water tank switching model

Peers Coordinate to Validate the Current State
Agree On Prior State
Compute locally
by operating on the same priors
One Agent Declares
‘solution’
candidate posterior state
Network Validates
Solution, adopting the
Posterior state

Coordination Platforms and/or Applications
Front End User Interface
Decentralized (Self-sovereign) Identity Decentralized Payment System
Core functionality for dApp
Application Token
Private or
Permissioned
Data Layer
(Thin) Centralized Backend
- Basic business logic
- ML microservices
- Application data
- APIs to other systems
- Other Oracles
Users of all roles

Recurring Example: Sweetbridge

Sweetbridge Vision: Protocol Stack
Core Features
•Stable Token driven to par by
commerce not by trading
•Self-lending
•Continuously Audited financial
system
•Financial base layer building
towards ecosystem level
operations management
algorithms via smart contracts
https://sweetbridge.com/public/docs/Sweetbridge-Whitepaper.pdf

Liquidity Protocol: 2 Currency System

Human Actions: Taking & Repaying UOUs

Network Systems:
Analogies and Examples

Engineered Multi-agent Network Analogy
https://www.frontiersin.org/articles/10.3389/frobt.2017.00012/full

Engineered Multi-agent Network Research
https://www.media.mit.edu/projects/blockchain-a-new-
framework-for-swarm-robotic-systems/overview/
Now!
Then! (c. 2005)
https://ieeexplore.ieee.org/document/1605401/

Transportation System Analogy
The naval architect’s
design spiral
Designing for and managing
the interface

Example: Transportation System Incentive Research
https://forum.stanford.edu/events/posterslides/CapriCongestionandParkingReliefIncentives.pdf
https://web.stanford.edu/~balaji/

Key Concepts
• Systems Engineering
• Model
• Model Based Systems Engineering
• Requirements

Systems Engineering Principles
Introduction to Systems Engineering
Project Performance (Australia) Pty Ltd
DO:
• Establish an objectively adequate problem definition before committing
significant resources to design and development
• Design a solution by dividing the big problem into a set of individually
sufficiently-well-defined smaller problems, by defining the required
characteristics of each element of the solution.
ELSE:
• Inadequate requirements have consistently been the single biggest
cause of project failures and losses in all sectors. The cost of inaction
typically exceeds the cost of prevention by a factor of 10-100 to one.
• Results in design errors, the need for much increased design verification,
and problems first revealed in system integration (or later).

Systems Engineering Design Process
SYSTEMS ENGINEERING FUNDAMENTALS, Department of
Defense, Systems Management College, January 2001

Requirements Key Points:
The 4-C's of requirements:
Ø Clear: understandable so that all stakeholders can participate in validation
and all developers know what to build and test
Ø Concise: Short requirements are more understandable and maintainable.
And, they can often be more precise when you use formalisms.
Ø Correct: Incorrect requirements will lead to reduced revenue, or major
rework.
Ø Complete: Incomplete requirements also leads to major rework and last-
minute schedule changes.

Requirements Key Points:
Ø The specification should not bias the design or implementation.
Ø Don't get ahead of yourself, you will do design later
Ø Design details make the system requirements for non-technical
stakeholders to understand
Ø Design details are irrelevant to system test.
Ø You may come up with better ideas for the design later, you do should not
have to change the system requirements unless your goals for the product
change.

Types of Requirements
Ø Performance
Ø To what extent is the function executed? What are the quality and quantity of
the function?
Ø Design
Ø How will we build? What are the technical needs?
Ø Derived
Ø Implied from a higher-level requirement
Ø Allocated
Ø Established by dividing a top-level requirement into multiple lower-level ones
Ø Operational
Ø How well the system serves users and under what conditions?
Ø Functional
Ø What are necessary the tasks or actions? Top-level for functional analysis

Requirements Analysis
• Inputs converted to outputs:
– Customer requirements –
– SE outputs from prior development efforts
• Controls:
– Laws and organizational policies and procedures –
– Tech base and other constraints
• Enablers:
– Multi-disciplinary product teams
– Decision and requirements database including system/configuration item
descriptions from prior efforts
– System analysis and control
REQUIREMENTS
ANALYSISInputs converted to outputs
Controls
Enablers
Outputs

Model Based Systems Engineering:

Model
§ A simplified version of a concept, phenomenon, relationship, structure or system
§ A graphical, mathematical or physical representation
§ An abstraction of reality by eliminating unnecessary components
The objectives of a model include:
Ø to facilitate understanding
Ø to aid in decision making, examine 'what if' scenarios
Ø to explain, control, and predict events
Introduction To Model-Based System Engineering (MBSE) and SysML
Laura E. Hart Lockheed Martin, IS&GS

System Model
• Requirements
What are the stakeholder goals, purposes, and success conditions for the system
Specification of black box behavior and characteristics
• Behavior
What the system has to do to meet the requirements
Transformations of inputs to outputs (functional/activity models)
State/Mode-based behavioral differences (state models)
• Structure
The parts that exhibit the behavior
The component hierarchy, elements, and stores
• Properties
The performance, physical characteristics and governing rules that constrain the structure and
behavior
• Interconnections
The way the structural elements arrange and communicate to achieve the required behavior
under the given constraints
Introduction To Model-Based System Engineering (MBSE) and SysML
Laura E. Hart Lockheed Martin, IS&GS

Model Based Systems Engineering in a Nutshell
Traditional Systems Engineering Model Based Systems Engineering
Image credit to NASA/JPL-Caltech

BlockScience Solution
BRAINSTORMING = DESCRIPTIVE MODELLING
BLOCKCHAIN LAYER
BLOCKCHAIN
DEVELOPMENT
TOKEN LAYER
EVOLUTIONARY
ECONOMY
ECONOMY
ENGINEERING
ICO LAYER
SALES
INVESTORS

Model Breakdown:
(Token or Economic Engineering)
BlockScience Solution
High Level Formal Specification
SPEC
High Level Analysis
SPEC SPEC SPEC
REQUIREMENTS
INTEGRATION
COMPONENT SIMULATION AND TESTING, REQUIREMENTS MET?

Sell Line
Triggering
Vault State
Legal Vault
State*
Liquidation
Event
Return Vault to Legal State
Vault States
LV/AV
Continuous Vault States
Liability Value as a % of Asset Value
Good Standing Valid Sell Line Triggering Default
Vault States: Original Customer
Requirements

Example from Sweetbridge: Sell Line Vault Controls
Collateralized debt positions have rules which trigger control actions which prevent loans from defaulting
https://images.sweetbridge.org/main/Sweetbridge-WP-LiquidityProtocolMath-v1-01.pdf
Hybrid System Controller designed to massively reduce the
probability of reaching the state of invalid vault despite it being
possible due to outside volatility in asset value

Automated Actions: Sell Line Vault Controls
Formal Proof creates a cushion between Valid and Triggering states with a tunable parameter, Theta
But we check our work numerically and use the simulations to guide parameter decisions
https://images.sweetbridge.org/main/Sweetbridge-WP-LiquidityProtocolMath-v1-01.pdf

Asset
Value
Asset
Value*
Figure 3: Asset and Liabilities at New State
Sweetbridge
Transaction
Fee
Liability
Value
Liability
Value*
-ΔLV
Penalty Fee
-ΔLV(1+PF)(1+TF)
Vault States: Revised Customer
Requirements
0 0.2 0.4 0.6 0.8 1 1.2
LV/AV
Vault States
Vault States with Sell Line
Liability Value as a % of Asset Value
Good Valid Sell Line Triggering Cannot Cover Fees Cannot Cover Liabilities

Defining State Variables in Economies

Defining Value Functions and Invariants

Sweetcoin Design Preserves an Invariant:
The Ratio of Fees incurred to Fees Paid!
We didn’t yet understand the generality of invariants when working on this

Sweetcoin Intrinsic Value– Marketprice Independence
Tokens in use:
Locked for the period
Based on level of service
Tokens owned
Purchase tokens
Sell tokens
Market value of
tokens owned
Discount capacity of
tokens owned
Network state:
Total tokens activated
Total platform use Token utility:
Financial value of using the
tokens based on costs offset
over a period of repeated use
use
From Discount Token Framework Published by Sweetbridge Inc
https://images.sweetbridge.org/main/WP-Sweetbridge-Discount-
Tokens.pdf
Discount Token
reduces platform fees by a percentage
F = total fees Network-wide
f = individual user fee without token
A = total activated tokens network-wide
a = individual user activated tokens
Discount Capacity = phi * a/A*F/f
User’s Discount = phi * a/(a+A)*(f+F)/f
phi = network-wide discount rate
zero fee when: a = f*A/( phi*F +(1-phi)*f)
Utility= Discount Capacity;
NOT dependent on Token Market Price

Discount Token as an On-chain Microservice
History of all
(f,a,f’)
Stored in Ledger
(f,a) f’f’= f*(1-phi * a/(a+A)*(f+F)/f)
f = fees incurred
a= tokens activated
activated tokens
remain locked for
N blocks in the future
f’ = fees due
after accounting
for locking a
F’ = Sum: f’
over N blocks
look back N blocks
F = Sum: f
A = Sum: a
System tends to the intended property
F’ = (1-phi)* F
But we added a low pass filter reduce noise in discount capacity experienced by Sweetcoin users

Going Beyond Invariants: Maximization and Convergence

Is “On Chain Control” Possible?

What about Games?
Actions and Reward are fixed: play best response
Design the game, but once deployed the game is fixed
But in the world of blockchain networks the game itself can change in time!

How does our "Control System” Relate to Games?
• Think of it as engineering how the ‘Game’ itself is evolving
• The players actions move the state within the ‘possible’ configurations
• We make no claims about what any player actual does
• We only make claims about what those ‘possible’ configurations are
• In practice this means careful selection of smart contract methods to be
mathematically consistent with fixed point properties in the manner of
Lyapunov Optimization
• Only After Characterizing the Possible configurations does it really make
sense to design incentive profiles over actions
https://en.wikipedia.org/wiki/Lyapunov_optimization

Model Testing: Component
Level Simulations

Moving through the systems design process:
VERIFICATION

Simulation Principles
§ Build tool using mathematical model
§ Determine assumptions
§ Define ranges
§ Validate Tool
§ Define test
§ Run test to answer right questions,
§ Deterministic vs Stochastic
§ Stochastic processes
§ Monte Carlo Simulation

Sweetcoin Macro-Economic Research
Uses of Sweetcoin in the network over time, time grouped averages over 100 unique Stochastic Experiments

Sweetcoin Macro-Economic Research
Statistics for Global Discount Ratios and Discount Capacity KPIs over 100 unique trials
At system launch few discounts are achieved
but the system evolves toward the designed
discount equilibrium point
The discount capacity of tokens grows roughly
proportionally with the growth in network
utilization as measured by fees incurred

Integration: System Level Simulations

Integration Key Points
• Systems Integration is the process of:
Assembling the constituent parts of a system in a logical, cost-effective way,
comprehensively checking system execution (all nominal & exceptional paths),
and including a full functional check-out.
• Systems Test is the process of:
• Verifying that the system meets its requirements
• Validating that the system performs in accordance with the customer/user
expectations
• Manage system integration and system test based upon subsystems that can be
end-to-end tested against system level requirements; manage system design &
development based upon components that can be independently developed and
checked.
• Success
• All subsystems integrated; all subsystem & system threads exercised
successfully.
• System is robust and is ready for formal requirements verification.

Bridgecoin Economy Research
System without Depositor Policy Implemented by Treasury
System with simple Depositor policy offering
interest bearing loans to lock up BRC

The 3Ms:
Measuring
Monitoring
Maintenance

Measuring, Monitoring and Maintenance
How:
• Collect data in real time from blockchain and other
data sources
Why:
• To be good stewards of shared infrastructure, system
(maintenance) tuning and well informed governance
requires data
• Owe it to your stakeholders to be informed about the
performance of your system
• Ability to gain insight, tune, foresee, and learn about
your blockchain environment
• Consider the operational life cycle of the product

Measuring, Monitoring and Maintenance
Example: CryptoKitties (AxiomZen)
https://drive.google.com/file/d/1soo-
eAaJHzhw_XhFGMJp3VNcQoM43byS/vie
w
• Low Stakes
Build a “toy” system but release it
into the real world to learn a lot. ‘It’s
just a game after all.’
• Low Risk
No major harm if something goes
wrong
• High Reward
Real data about real activity with
respect to an explicit incentive is
available and can be analyzed!

Cryptokitties: NFTs, Functions and States
https://github.com/BlockScience/EthereumStats/blob/master/KittyExplorer.ipynb

GiveBirth() and the Midwife Role
// Send the balance fee to the person who made birth happen.
msg.sender.send(autoBirthFee);

Births By Midwife
The all time top 10 Midwives

Though Not as Dominant as it appears…

Midwives Go Professional: Smart Contracts
Instead of “external accounts” — Smart contracts specialized to call give Birth Emerged a few weeks in

Smart Contracts and Serious Multi-tasking

Birthing Smart Contacts: Profit by Caller
Restricted to top Midwife Accounts

Birthing Smart Contacts: Profit by Called
Serious differences in performance despite a flat reward function

There can be only one… you lose a lot
Each kitty can only be born once so there is a trade off between gas fee on the call and chance of winning

Identity and Privacy
All blockchain ‘accounts’ have public key addresses
Networks are Psuedo-nonymous
Government Issued
“Legal” Identity
Public Ledgers are a double-edged sword not a Panacea
Layered Architectures and Nuanced thinking around Policy
and Regulation are required build and regulate systems that
store, manage or make decisions using
Personally Identifying Information (PII)
Map

Regulation and Governance
Technology is what can be done
but Society needs to think about
What the technology is used for.
When economic ‘robotic agents’ are part of the economy….
Who decides what their objective functions are allowed to be?
Who is responsible for monitoring the health of the economy?
… for tuning network or agent parameters?
… for decommissioning them?
Do we need professional engineering licenses for economic agents?
How do we make sure they aren’t taking advantage of people?
… or incentivizing or enabling nefarious behavior?

Scifi Dystopian Future?
A synthetic world interwoven with the physical one
in which autonomous software agents interact with
each other, their environment and humans.
Trending up
Trending down
Emergence of a hyper-intelligent AI that has central
command of legions of robotic agents; coordination
issues: Byzantine General’s Problem

Token engineering presentation 5 13-18

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Token engineering presentation 5 13-18

Ähnlich wie Token engineering presentation 5 13-18 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Token engineering presentation 5 13-18