INTRODUCTION

# challenges of decentralized setting

Game-theoretical standpoint for all actors

### 01

Trust in the network

### 02

INTRODUCTION

Strict verification requirement

### 03

Nondeterministic computations

### 04

https://truebit.io - can be used in case of deterministic computations

Monte Carlo methods

# why rendering?

source: https://www.behance.net/gallery/21615831/Testing-render-engines

INTRODUCTION

L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'
$L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'$
\cos\theta = (\vec{\omega}' \cdot \vec{n})
$\cos\theta = (\vec{\omega}' \cdot \vec{n})$

# trust and security

INTRODUCTION

Concent

### 01

Intel SGX technology

### 02

• Is a service in the Golem network, which aims to improve the integrity and security of transactions
• Technology which can be used to implement secure remote computation

# a brief intro to golem tech

### Golem Technology

and Nondeterminism

# first poc

Minilight (Python)

GOLEM TECHNOLOGY

Focus on computations / computation-centric use case

Specific renderer hardcoded in provider

(POC 0.5 - Minilight)

# first poc

pbrt (C++)

GOLEM TECHNOLOGY

Focus on computations / computation-centric use case

• Trusted computing nodes
• Lack of transaction framework

• No payments

Basic protocol

### 03

• Rendering task is abstracted out and decoupled from the Golem client code. The first implementation used PBRT renderer as a rendering backend

# first poc

First POC

### 01

Intranet computations

### 02

GOLEM TECHNOLOGY

Execution environment:

• Multiple computational backends
• Multiple operating systems
• Multiple hardware configurations

### 03

• Timeouts (global, local)

GOLEM TECHNOLOGY

# computation environment

GOLEM TECHNOLOGY

Physical infrastructure: Heterogenous p2p network

### 01

Logical components: Requestors, providers, (optional) concents

GOLEM TECHNOLOGY

Verification

# security considerations

GOLEM TECHNOLOGY

Provider security

• Isolating host from possibly malicious software

### 01

Requestor security

### 02

• Trust (i.e. reputation)
• Results verification

• Keep track of providers and notion of trust

Infrastructure security

### 03

• no unauthorized internet access (e.g. botnet protection)

# Infrastructure and actors

GOLEM TECHNOLOGY

New topology and requirements – P2P

### 01

Distribution of execution environments

### 02

Notion of trust – reputation of the actors

### 03

New integrations – new use-cases

### 04

Actors in the network

# Incentives and economy

GOLEM TECHNOLOGY

Game-theoretical conditions for all actors

### 01

Requestor incentives

### 02

Provider incentives

### 03

• Notion of trust in the network (local and global schemes)

• Known verification requirements and algorithms

• Open market

• Wants to compute cheap, fast and get a high-quality result

• Wants to compute fast and make the highest possible profit

# payments inside the network

GOLEM TECHNOLOGY

Reward scheme:

### 01

• Every integration can use any custom reward scheme, as long as it is compliant with the transaction framework

• Key parties are:

• task creators (Requestors): how they pay for computations and software

• Providers: how they are rewarded (eg. per hour? per task?)

• Developers: payment for software (free? donation? per node? per use? per CPU hour

• Ethereum network is used to transfer value and information between the peers

Golem Technology

# Sources of nondeterminism

NONDETERMINISM

Random number generators

### 02

Floating point encoding standards on different platforms:

• CPUs
• GPUs

# Sources of nondeterminism

NONDETERMINISM

Random number generators

### 02

Float encoding standards

on different platforms:

• CPUs
• GPUs

# Sources of nondeterminism

NONDETERMINISM

Random number generators

### 02

Float encoding standards

on different platforms:

• SIMT or SMT in the case of GPUs

• CPUs
• GPUs

# Sources of nondeterminism

NONDETERMINISM

Random number generators

### 02

Float encoding standards

on different platforms:

• SIMT or SMT in the case of GPUs

### 03

• CPUs
• GPUs

Nondeterministic implementation

of MC methods

# problems with nondeterminism

### 01

Rendering

NONDETERMINISM

• Deterministic input

• Nondeterministic computation

• Nondeterministic results

# problems with nondeterminism

Machine Learning

### 02

• Deterministic or randomized input

• Deterministic or nondeterministic computations

• Nondeterministic results

NONDETERMINISM

# problems with nondeterminism

Proof of Work

• Deterministic input

• Nondeterministic amount of work required

• Deterministic and efficient verification

• The exact amount of performed computations is hard to verify

NONDETERMINISM

# Nondeterminism and consensus

### 01

NONDETERMINISM

Nondeterministic state

• Nondeterministic results cannot be directly compared

• Each node may see a slightly different result

• A similarity measure is required

# Nondeterminism and consensus

Golem's setting

• Consensus between a very small  (usually two) number of nodes

• Means of dealing with a dispute are implemented

NONDETERMINISM

Introduction

# Basic probability

Probabilistic space

### 01

Probabilistic measure via density function

### probabilistic space

– domain

probabilistic measure

### probability density function

MONTE CARLO METHODS

\Omega
$\Omega$
dP
$dP$
\int_{\Omega} dP(x) = 1
$\int_{\Omega} dP(x) = 1$
p(x) \ge 0
$p(x) \ge 0$
dP(x) = p(x)dx
$dP(x) = p(x)dx$
\int_{\Omega} dP(x) = \int_{\Omega}p(x) dx = 1
$\int_{\Omega} dP(x) = \int_{\Omega}p(x) dx = 1$

# Basic probability

Random variable

### random variable

MONTE CARLO METHODS

P(x \in S) = \int_{S} dP(x) = \int_{S} p(x)dx
$P(x \in S) = \int_{S} dP(x) = \int_{S} p(x)dx$
S \subseteq \Omega
$S \subseteq \Omega$

# ”

A random variable, usually written X, is a variable whose possible values are numerical outcomes of a random phenomenon. There are two types of random variables, discrete and continuous.

# Basic PROBABILITY

Expected value

### sum of i.i.D. random variable

MONTE CARLO METHODS

\mathrm{E}(x) = \int_{\Omega} x dP(x) = \int_{\Omega} x p(x) dx
$\mathrm{E}(x) = \int_{\Omega} x dP(x) = \int_{\Omega} x p(x) dx$
\mathrm{Var}(X) = \mathrm{E}(X - \mathrm{E}X)^2
$\mathrm{Var}(X) = \mathrm{E}(X - \mathrm{E}X)^2$
\mathrm{E}(aX + bY) = a\mathrm{E}X + b\mathrm{E}Y
$\mathrm{E}(aX + bY) = a\mathrm{E}X + b\mathrm{E}Y$
\mathrm{Var}(aX + bY) = a^2\mathrm{Var}X + b^2\mathrm{Var}Y
$\mathrm{Var}(aX + bY) = a^2\mathrm{Var}X + b^2\mathrm{Var}Y$

Variance

# Basic PROBABILITY

Vector of random variables

### Standard deviation

$$P(\mathrm{E}X = \lim_{N \rightarrow \infty} \frac{1}{N} \sum_{k=1}^{N}X_k) = 1$$

### Strong law of large numbers

Strong law of large numbers

### 06

MONTE CARLO METHODS

\overline{X} = \frac{X_1 + X_2 + \ldots + X_n}{n}
$\overline{X} = \frac{X_1 + X_2 + \ldots + X_n}{n}$
\mathrm{E}\overline{X} = \frac{\mathrm{E}X_1 + \mathrm{E}X_2 + \ldots + \mathrm{E}X_n}{n} = \frac{n\mathrm{E}X}{n} = \mathrm{E}X
$\mathrm{E}\overline{X} = \frac{\mathrm{E}X_1 + \mathrm{E}X_2 + \ldots + \mathrm{E}X_n}{n} = \frac{n\mathrm{E}X}{n} = \mathrm{E}X$
\mathrm{Var}(\overline{X}) = \frac{\mathrm{Var}(X_1) + \mathrm{Var}(X_2) + \ldots + \mathrm{Var}(X_n)}{n^2} = \frac{n\mathrm{Var}(X)}{n^2} = \frac{\mathrm{Var}(X)}{n}
$\mathrm{Var}(\overline{X}) = \frac{\mathrm{Var}(X_1) + \mathrm{Var}(X_2) + \ldots + \mathrm{Var}(X_n)}{n^2} = \frac{n\mathrm{Var}(X)}{n^2} = \frac{\mathrm{Var}(X)}{n}$
\sigma \propto \frac{1}{\sqrt{N}}
$\sigma \propto \frac{1}{\sqrt{N}}$

# ”

Monte Carlo methods are a broad class of computational algorithms that rely on repeated random sampling to obtain numerical results.

Can be used to solve any problem having a probabilistic interpretation.

By the law of large numbers, integrals described by the expected value of some random variable can be approximated by taking the empirical mean of independent samples of the variable.

### – wikipedia

MONTE CARLO METHODS

# monte carlo integration

Goal

• Find the best possible approximation of the integral by sampling the integrated function at a finite set of points

### Integral

MONTE CARLO METHODS

$$\int_{S}f(x)dx$$

Expected Value approximation

### Average with respect to some density p

$$\mathrm{E}(f(x)) = \int_{\Omega} f(x)p(x) dx \approx \frac{1}{N} \sum_{k=1}^{N}f(x_k)$$

### Average estimation - uniform samples

$$P(\mathrm{E}X = \lim_{N \rightarrow \infty} \frac{1}{N} \sum_{k=1}^{N}X_k) = 1$$

### Strong law of large numbers

$$\mathrm{E}(f(x)) = \int_{\Omega} f(x)dP(x) = \int_{\Omega} f(x)p(x) dx$$

# monte carlo integration

Mean of a function

### N uniformly distributed samples

$$\mu(\Omega) I = \mu(\Omega) \mathrm{E}(f(x)) \approx \mu(\Omega) \frac{1}{N} \sum_{k=1}^{N}f(x_k)$$

### Integral Estimator

MONTE CARLO METHODS

p(x) = \frac{1}{\mu(\Omega)}
$p(x) = \frac{1}{\mu(\Omega)}$
\mathrm{E}(f(x)) = \int_{\Omega} \frac{1}{\mu(\Omega)} f(x) dx = \frac{1}{\mu(\Omega)} \int_{\Omega} f(x) dx = I
$\mathrm{E}(f(x)) = \int_{\Omega} \frac{1}{\mu(\Omega)} f(x) dx = \frac{1}{\mu(\Omega)} \int_{\Omega} f(x) dx = I$
\mu({\Omega}) I = \mu({\Omega}) \frac{1}{\mu(\Omega)} \int_{\Omega}f(x)dx = \int_{\Omega}f(x)dx
$\mu({\Omega}) I = \mu({\Omega}) \frac{1}{\mu(\Omega)} \int_{\Omega}f(x)dx = \int_{\Omega}f(x)dx$
x_k \sim U(\Omega)
$x_k \sim U(\Omega)$

Integral estimation using mean value

# monte carlo integration

Integral expressed in terms of an arbitrary distribution

### expected value of a slightly modified function

$$\int_{\Omega}f(x)dx = \int_{\Omega} \frac{f(x)}{p(x)}p(x) dx \approx \frac{1}{N} \sum_{k=1}^{N}\frac{f(x_k)}{p(x_k)}$$

### Integral estimation - i.i.D. samples sampled from the distribution specified by P

where

independent identically distributred

### a vector of N i.i.d. variables

MONTE CARLO METHODS

x_k \sim p
$x_k \sim p$
x_k
$x_k$

$$\mathrm{E}(f(x)) = \int_{\Omega} f(x)dP(x) = \int_{\Omega} f(x)p(x) dx$$

$$\mathrm{E}(\frac{f(x)}{p(x)}) = \int_{\Omega} \frac{f(x)}{p(x)} p(x) dx = \int_{\Omega} f(x) dx$$

# monte carlo integration

### Standard deviation

Problem of diminishing return

### 06

MONTE CARLO METHODS

\sigma \propto \frac{1}{\sqrt{N}}
$\sigma \propto \frac{1}{\sqrt{N}}$

# ”

To halve the error the number of samples has to be quadrupled.

Variance reduction techniques

### 07

• Choosing density wisely we can greatly reduce initial variance (Importance Sampling)

# monte carlo integration

### Standard deviation

Problem of diminishing return

### 06

MONTE CARLO METHODS

\sigma \propto \frac{1}{\sqrt{N}}
$\sigma \propto \frac{1}{\sqrt{N}}$

# ”

To halve the error the number of samples has to be quadrupled.

Variance reduction techniques

### 07

• Domain partitioning (Stratified Sampling)

# ”

In computer graphics, the rendering equation is an integral equation in which the equilibrium radiance leaving a point is given as the sum of emitted plus reflected radiance under a geometric optics approximation.

### – wikipedia

RENDERING EQUATION

L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'
$L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'$
\cos\theta = (\vec{\omega}' \cdot \vec{n})
$\cos\theta = (\vec{\omega}' \cdot \vec{n})$

Energy

Flux

### Flux

$$\theta$$

RENDERING EQUATION

Q
$Q$
\Phi = \dfrac{dQ}{dt}
$\Phi = \dfrac{dQ}{dt}$
L(x,\vec{\omega}) = \dfrac{d^2\Phi}{\cos\theta dA d\vec{\omega}}
$L(x,\vec{\omega}) = \dfrac{d^2\Phi}{\cos\theta dA d\vec{\omega}}$
\cos\theta = (\vec{\omega} \cdot \vec{n})
$\cos\theta = (\vec{\omega} \cdot \vec{n})$
\vec{n}
$\vec{n}$
\vec{\omega}
$\vec{\omega}$
dA\cos\theta
$dA\cos\theta$
• Radiant flux per unit solid angle per unit projected area

• Intuitively, radiance expresses how much power (flux) arrives at (or leaves from) a certain point on a surface, per unit solid angle, and per unit projected area

• Time rate of flow of radiant energy

• This quantity expresses how much total energy flows from/to/through a surface per unit time

• Energy of a collection of photons

dA
$dA$

Bidirectional Reflectance Distribution Function (BRDF)

• A function that defines how light is reflected from a surface

### integral form

RENDERING EQUATION

\vec{n}
$\vec{n}$
\vec{\omega}
$\vec{\omega}$
\vec{\omega} '
$\vec{\omega} '$
\theta
$\theta$
\rho(x,\vec{\omega}', \vec{\omega}) = \dfrac{dL_r(x,\vec{\omega})}{L_i(x,\vec{\omega}') \cos\theta d\vec{\omega}'}
$\rho(x,\vec{\omega}', \vec{\omega}) = \dfrac{dL_r(x,\vec{\omega})}{L_i(x,\vec{\omega}') \cos\theta d\vec{\omega}'}$
dL_r(x,\vec{\omega}) = \rho(x,\vec{\omega}' ,\vec{\omega}) L_i(x,\vec{\omega}') \cos\theta d\vec{\omega}'
$dL_r(x,\vec{\omega}) = \rho(x,\vec{\omega}' ,\vec{\omega}) L_i(x,\vec{\omega}') \cos\theta d\vec{\omega}'$
L_r(x, \vec{\omega}) = \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'
$L_r(x, \vec{\omega}) = \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'$
x
$x$
\cos\theta = (\vec{\omega} ' \cdot \vec{n})
$\cos\theta = (\vec{\omega} ' \cdot \vec{n})$

$$x$$

dA
$dA$
L_r
$L_r$
d\vec{\omega}
$d\vec{\omega}$
L_i
$L_i$
L_i
$L_i$
L_i
$L_i$
L_i
$L_i$
L_i
$L_i$

# rendering equation

### 01

Rendering equation

### Rendering equation

RENDERING EQUATION

L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + L_r(x, \vec{\omega})
$L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + L_r(x, \vec{\omega})$
L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'
$L_o(x, \vec{\omega}) = L_e(x, \vec{\omega}) + \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) L_i(x, \vec{\omega}') \cos\theta d\vec{\omega}'$
\cos\theta = (\vec{\omega}' \cdot \vec{n})
$\cos\theta = (\vec{\omega}' \cdot \vec{n})$

Operator formulation

### operator defined as

T = L_e + TL
$T = L_e + TL$
< T g > (x, \vec{\omega}) = \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) g(x, \vec{\omega}') \cos\theta d\vec{\omega}'
$< T g > (x, \vec{\omega}) = \int_{\Omega} \rho(x, \vec{\omega}', \vec{\omega}) g(x, \vec{\omega}') \cos\theta d\vec{\omega}'$
\cos\theta = (\vec{\omega}' \cdot \vec{n})
$\cos\theta = (\vec{\omega}' \cdot \vec{n})$

# rendering equation

Neumann Series

### neumann series expansion

$$T = \sum_{k=0}^{\infty} T^kL_e$$

### Compact notation

• Renderers - black box engines

• The rendering equation expressed via Neumann series expansion suggests that the final solution can be composed of independently computed results.

• These partial results are computed by renderers, which can be treated as black box computation engines

RENDERING EQUATION

T = L_e + TL_e + T^2L_e + T^3L_e + \ldots
$T = L_e + TL_e + T^2L_e + T^3L_e + \ldots$

# rendering process

RENDERING EQUATION

# ”

Rendering or image synthesis is the automatic process of generating a photorealistic or non-photorealistic image from a 2D or 3D model (or models in what collectively could be called a scene file) by means of computer programs. Also, the results of displaying such a model can be called a render. A scene file contains objects in a strictly defined language or data structure; it would contain geometry, viewpoint, texture, lighting, and shading information as a description of the virtual scene. The data contained in the scene file is then passed to a rendering program to be processed and output to a digital image or raster graphics image file.

# ”

(in this context) a computer program used to generate photorealistic images from a scene file (consisting of 3D models and description of materials and lights)

# path tracing

RENDERING EQUATION

Path formulation

### 01

• Markov Chain approach

• Independent evaluation of each path

# examples of path grouping

RENDERING EQUATION

• Each tile is rendered independently, the final image is composed of tiles rendered with full quality

• Multiple, independent full resolution images are rendered. Each one uses only a fraction of samples per pixel as compared to the final result. The final image is obtained by means of averaging these intermediate results

# monte carlo methods

Verification challenges

# Verification challenges

VERIFICATION CHALLENGES

Game-theoretical approach

### 01

Verification process outline

### 02

• Each rational participant wants to maximize his/her benefit

• 1st step - automatic verification

1. Classifier can be easily replaced (it is a plugin architecture)

2. The main classifier can consist of multiple classifiers and image comparison algorithms

• 2nd step - manual verification and acceptance/rejection

# Verification challenges

VERIFICATION CHALLENGES

Automatic verification

### 03

• Outlier removal method

• Verification based on redundant computations (probabilistic)

# Verification challenges

VERIFICATION CHALLENGES

Manual verification

### 04

• The final result may be accepted or rejected manually

# consequences of decentralization

Requestor prepares scenes and sends them together with the resources to a render farm

### 01

Render farm splits the task and distributes computations between nodes

### 02

Nodes compute partial results which are composed into final images/animations

### 03

The results are sent back to the requestor

DECENTRALIZATION

# consequences of decentralization

### decentralized setting

Requestor wants a valid result for the lowest price possible in a specified timeframe:

• Must carefully set the number of samples for a valid result to avoid unnecessary computation

• Won't pay for invalid results

• Requires fair protocol in case of invalid results

DECENTRALIZATION

# consequences of decentralization

### decentralized setting

Provider wants to earn as much as possible for the least possible resources provided:

• Can try to generate the image of lesser quality and use fewer samples than the requestor requested

• May not be paid for valid results and needs to have a way of recovering the payment

• Protocol must be fair

DECENTRALIZATION

# verification - monte carlo rendering example

VERIFICATION - MC

Blender (Cycles renderer) use-case

### 01

• Bit-by-bit verification is not viable

• Each tile has to be either marked as valid or invalid by automatic verification algorithm

# verification - monte carlo rendering example

VERIFICATION - MC

Example of classifier implementation

• Local verification

• Sample rectangles are rendered with the same parameters as the main tile

• Each sample must match the corresponding rectangle in the tile

• Total area of sample rectangles is only a small fraction of the tile area

# verification - monte carlo rendering example

VERIFICATION - MC

Example of classifier implementation

• Redundancy

• Rendering each tile multiple times and comparing

• Rendering redundantly but not necessarily duplicating all pixels

• Multiple schemes are possible, which makes it harder to cheat

# verification - monte carlo rendering example

VERIFICATION - MC

It is probabilistic

• Tunable redundancy
• Tunable verification thresholds

• Tunable trust requirements (e.g. when SGX nodes are present)

### summary

Classifier only assists

# image comparison and verification

COMPARISON AND VERIFICATION

Formal problem statement

### Verification prerequisites

p = q
$p = q$
b \in B
$b \in B$
• For the same input parameters and renderer run in exactly the same conditions we have

### Approach 1 - estimate the probability

provided that we know

P(q = p)
$P(q = p)$
p, b, R
$p, b, R$

input bitmap

R \in \Re
$R \in \Re$
q \in P
$q \in P$
p \in P
$p \in P$

renderer

unknown parameters used to render

parameters specified by the requestor

b
$b$
R(q) = R(p) = b
$R(q) = R(p) = b$

### APPROACH 2 - ESTIMATE THE PROBABILITY (preferred solution)

provided that we know

P(R(p) = b)
$P(R(p) = b)$
p, b, R
$p, b, R$
R(p)
$R(p)$

but we do not want to recompute the whole

Estimation

# image comparison and verification

COMPARISON AND VERIFICATION

Example approach

### transform

• Two transforms

• ​​Wavelet transform

• Edge enhancing transform

• Two measures

• SSIM (structural similarity)

• MSE (mean squared error)

### Similarity measure

Similarity of images

### 01

T_j \colon B \rightarrow B
$T_j \colon B \rightarrow B$
M_i \colon B \times B \rightarrow \mathbb{R}
$M_i \colon B \times B \rightarrow \mathbb{R}$
• a decent algorithm is required to help the classifier decide if two bitmaps are similar enough to be treated as the result of the same computation

# image comparison and verification

COMPARISON AND VERIFICATION

### Picture w/ no transform

Importance of the transforms

### Comparison of two bitmaps

• Picture w/ no transform vs Picture w/ edge enhancing transform (one SPP difference in images)

m_{ji} = M_i(T_j(b_1), T_j(b_2))
$m_{ji} = M_i(T_j(b_1), T_j(b_2))$

# image comparison and verification

COMPARISON AND VERIFICATION

### Picture w/ edge enhancing transform

Importance of the transforms

### Comparison of two bitmaps

• Picture w/ no transform vs Picture w/ edge enhancing transform (one SPP difference in images)

m_{ji} = M_i(T_j(b_1), T_j(b_2))
$m_{ji} = M_i(T_j(b_1), T_j(b_2))$

# other use-cases

COMPARISON AND VERIFICATION

Machine Learning

### 01

• Golem can be used to find the best set of hyperparameters for a given model

• Hyperparameters describe network structure, eg. number of layers, number of nodes in each layer. They are set before training

• Each provider is doing a full training of a neural network but for different values of hyperparameters

• Requestors can use different algorithms for searching parameter space, eg. grid search, random search, bayesian optimization search

• Each dot in the picture represents one set of parameters, ie. one network trained by Provider

# other use-cases

COMPARISON AND VERIFICATION

Machine Learning - Verification

### 02

• Neural network training is a sequential algorithm

• Feeding sets of batches to the network is one iteration step. After every step, the provider computes the hash of the network state and sends it to requestor

• Requestor asks provider for randomly chosen states and verifies that transition to the next state was done correctly

• Each rectangle represents one network state. The Requestor checks the transition between randomly chosen states

# other use-cases

COMPARISON AND VERIFICATION

Proof of Work

### Nonces for PoW

S=\{ 0, 1, \ldots, 2^{n-1} \}
$S=\{ 0, 1, \ldots, 2^{n-1} \}$
\sigma = \Big(
$\sigma = \Big($
0,\;\;\;\;\: 1,\;\;\;\;\: 2,\;\;\;\;\:\, \ldots, 2^{n-1}
$0,\;\;\;\;\: 1,\;\;\;\;\: 2,\;\;\;\;\:\, \ldots, 2^{n-1}$
\sigma(0), \sigma(1), \sigma(2), \ldots, \sigma(2^{n-1})
$\sigma(0), \sigma(1), \sigma(2), \ldots, \sigma(2^{n-1})$
\Big)
$\Big)$
\bigg\{
$\bigg\{$
\bigg\{
$\bigg\{$

$$S_1$$

$$S_K$$

$$\bigcup_{i=1}^{K}S_i = S$$

$$S_i \cap S_ j= \emptyset$$

$$i \neq j$$

for

$$\ldots$$

\mathrm{Res}_i = \{\{ k \in S_i | H(k \oplus \omega) \leq t \}, \{ n \in S_i | H(n \oplus \omega) \leq T \} \}
$\mathrm{Res}_i = \{\{ k \in S_i | H(k \oplus \omega) \leq t \}, \{ n \in S_i | H(n \oplus \omega) \leq T \} \}$

### PoW targets

\omega
$\omega$
H
$H$
T
$T$
t
$t$

PoW input string

PoW hash function

PoW target

PoW intermediate target (used during verification),

T < t
$T < t$

# what is concent?

• Providers should be paid for calculations they do

• Requestors must get proper results (honest calculations)

• If something goes wrong, an optional third party may be utilized to solve the dispute

### what is concent?

• It is a web service (which ultimately may be distributed)

• It is a special type of node in the Golem Network

• Its purpose is to improve the fairness of transactions

• It is passive

• It is optional

CONCENT

# what concent does

Enforcing communication:

• After a Requestor gives a task to a Provider and the Provider starts to compute, the communication must follow the protocol. If one party goes offline or rejects accepting proper messages, Concent can enforce the right communication, or ensure that the malicious party takes responsibility for the broken communication

CONCENT

# what concent does

• Verification is performed by Requestors. If a Requestor rejects the correct result, the Provider calls Concent which performs additional verification. It is similar to the one performed by the Requestor but stronger. If the result turns out to be correct then Concent forces the Requestor to pay

CONCENT

# what concent does

Enforcing payment:

• If a Requestor does not pay on time for accepted results, then Concent will charge payments from the Requestor's deposit

CONCENT

# how concent works

Requestor sends a task to a Provider

### 01

Provider calculates the task and sends the result to the Requestor

### 02

Requestor verifies and accepts the result

### 03

If the result is correct, the Requestor pays, if not they do not pay for it

CONCENT

# Concent's role in solving conflicts

All Concent use-cases are meant to overcome flaws like attacks/frauds

### 01

Use-cases can be initialized by one or two parties

### 02

Use-case starts when a party does not receive a response, is not paid on time, or if their results are wrongly rejected

### 03

To use Concent, parties must agree to it at the beginning by putting deposits in GNT which are transferred to a dedicated Ethereum contract

### 04

Concent has special permissions on deposits

### 05

Concent is not a free service

CONCENT

# why concent?

### can fairness in transactions between requestors and providers be ensured?

Fairness means that Requestors do not pay for incorrect results and must always pay for correct results

### 01

Main options for ensuring fairness in transactions:

• Use trusted third-party

• Use blockchain and/or consensus in network

### 02

Verification is critical for defining Concent and non-Concent solutions

CONCENT

# is concent reliable?

A Priori assumption: Providers and Requestors trust Concent

### 01

Under normal conditions Concent is called very rarely

### 02

Concent as a service is a single-point-of-failure and may be vulnerable to DDoS attacks

### 03

The principle is that Golem Network can calculate tasks even if Concent is down

### 04

Concent service will be more decentralized in the future

### 05

It suffices for Concent to be up 99% of time

CONCENT

# can concent be decentralized?

In the future we plan to allow others to run valid Concent services (i.e. software developers may want to run Concent for their own applications)

### 01

Technologies like SGX provide trustworthy and non-controlled calculations that are considered decentralized and i.e. can perform additional verification

CONCENT

SGX TECHNOLOGY

# ”

SGX is a set of CPU instructions and hardware platform enhancements that enable apps to create private areas within which code and associated data can be stored safe from compromise during execution. If used correctly, this protection can prevent compromise due to attacks from privileged software and many hardware attacks

# sgx technology

Verifiable computation:

• Prevents BIOS/OS/VMM/SMM/drivers attacks

• Prevents bus snooping and memory tampering

• Provides hardware measurement mechanism

• Provides hardware attestation (local and remote)

• Provides hardware sealing (to the enclave and to the author)

### 02

Example usages:

• User authentication

• Sensitive data processing

• Verifiable computation

SGX TECHNOLOGY

# sgx technology

Enclaves:

• Similar in spirit to a DLL, SO or Dynamic Library, plus some additional configuration data

• Limited to computations only (no direct IO or OS calls allowed)

• IO or OS calls available by means of OCALLs mechanism (configured statically)

• Enclave

• Run and hosted in an untrusted environment

• Once instantiated it becomes a trusted part of the app (As there may appear attacks on SGX which cannot be foreseen today)

### 03

SGX TECHNOLOGY

Enclave creation:

• Binary payload (similar to a dll) which is run inside the enclave

• Configuration data:

• Stack size

• Heap size

• Enclave author’s public key

• Software version

• Product id

### 01

Enclave Launch:

• Currently launched by Launch Enclave provided by Intel

### 02

Enclave Usage:

• Communication via ECALLs and OCALLs

SGX TECHNOLOGY

# Actors/Parties

ISV

Application

### 02

Application SGX Enclave

Intel IAS

### 04

SGX TECHNOLOGY

• Enclave developer; assists in attestation; for now must be registered to Intel

• Provides measurement and mrsigner for attestation and sealing; trustworthy

• Intel Attestation Service - used to verify EPID during remote attestation

# security related activities

Measurement

Attestation

Sealing

### 03

• mrenclave – hash of vanilla enclave state including its security properties – used to prove that the enclave was instantiated correctly

• Local – between enclaves on a single machine

• Remote – to prove the enclave validity to a remote user/client

• Used to securely store persistent data

• Seal to current enclave – only the enclave with the matching measurement can unseal the data

• To the author – used to unseal data in enclaves developed by the same author

SGX TECHNOLOGY

# cons of SGX TECHNOLOGY

• Intel presence is required to attest quotes and partially to launch enclaves

• Launching an enclave with all SGX features enabled requires Launch Enclave provided by Intel

• Currently the Intel Attestation Service (IAS) is necessary for the remote attestation to work

• ISV requires Intel approval

• Remote attestation procedure does not require IAS by design and a perfectly valid remote attestation process without IAS can be implemented (once IAS is liberated)

SGX TECHNOLOGY

# SGX and golem

How SGX can be used to the advantage of Golem

### 01

• Software Developer is ISV and currently can serve as attestation service - and connect to Intel to assure correctness of the enclave in question

• Once a proof for an enclave is created by IAS, the proof can be subsequently verified offline

• The protocol used to communicate with IAS is not critical from a security standpoint

• Requestor and Concent are "hosting" Developers code

SGX AND GOLEM

# SGX and golem

How SGX nodes can be added to Golem

### 03

• Even though SGX nodes are present and arbitrage is not as necessary as it was, additional logic related to licensing models may still be required and should be implemented in a decentralized and secure manner

SGX AND GOLEM

• When (if) SGX is liberated, then only ISV is required to have a high reputation (from requestors' point of view)

• ISV has skin in the game to provide a valid enclave, so they should be trusted with attesting enclaves

SGX in Golem - possible future

# SGX and golem

How SGX nodes can be added to Golem

### 03

• The most resource consuming aspect of Concent is additional verification

• Concent can delegate verification to SGX nodes increasing scalability and keeping the same level of trustworthiness. It may even happen that SGX nodes computations are considered as more trustful. This makes the most sense if SGX nodes compute noticeably slower than regular nodes

• In such a setting a regular node may not be incentivized to call SGX nodes directly, but there would be a special case where an SGX node would be able to provably repeat computation and compare results with questionable ones

• Other solutions

• May encompass sharing logic between one group of nodes and the state and history on other nodes

SGX AND GOLEM

# SGX and golem

Computations and Verification with SGX

### 04

• We can run the whole computation inside an SGX enclave (if possible) and if the result is returned - it is the result of a valid computation and no verification is needed

• The aforementioned approach may result in less security guarantees than the default SGX enclaves, but should still be much more secure than computations carried out the regular way

SGX AND GOLEM

# SGX and golem

Computations and Verification with SGX

### 04

• We can run the whole computation inside an SGX enclave (if possible) and if the result is returned - it is the result of a valid computation and no verification is needed
• The aforementioned approach may result in less security guarantees than the default SGX enclaves, but should still be much more secure than computations carried out the regular way
• SGX enclaves are restricted to computations only, but more general platforms allowing arbitrary computations inside the enclave are being researched and developed. We closely cooperate with Invisible Things Labs, the team/company solving problems in this exact area

SGX AND GOLEM

# SGX and golem

How SGX can help with verification

### 05

• We can use SGX nodes and redundancy to help verify (with tunable probability) the results from regular nodes

• Just as regular redundancy, but we know that results from SGX nodes are significantly more trustworthy and can be used as reference data

• Additional verification logic can be implemented and run in an enclave whereas the main computation is performed on the regular host machine, but with intermediate results being sent to the Enclave

• Performance

• SGX supports EPC paging (enclave's private memory protected from the host and external, physical attacks), but it may be harmful to the performance

• Depending on the performance impact of SGX, an appropriate fraction of calculations should be delegated to SGX nodes, the less impact, the more subtasks can be sent to SGX nodes (possibly for higher price)

SGX AND GOLEM

# SGX and golem

Summary

### 01

• In a perfect world SGX or similar technology:

• Should provide mechanism for verifying that declared computations indeed took place

• Should assure privacy of sensitive data

• Should not impose large computational overhead

• Requestors shouldn’t have to verify the results locally at all

• SGX or similar technology can be used to help decentralize server solutions in a secure manner

• The Golem network may consist of regular nodes, nodes with SGX and Concents using SGX

• Non-SGX nodes are first class citizens but may require more mechanisms to assure valid results produced by them (e.g. local verification, redundant computations, reputation)

• Such technology seems to be a perfect match for nondeterministic computations (as defined in previous sections)

SGX AND GOLEM

# summary

• There is much more to Golem than verification of broadly defined nondeterministic tasks, but this seems to be one of the most prominent challenges in a decentralized and trustless setting
• A detailed introduction to Monte Carlo rendering was presented to give you a better understanding of the problems one has to tackle when fully a decentralized infrastructure is to be prepared. As most of the issues are well known, applying them in a trustless decentralized setting requires additional thoughts in order to balance: quality, security, pricing, and efficiency
• Our approach to this challenge was presented and we shared a few ideas and directions we’re already exploring in regard to improving general network security without sacrificing too much efficiency
• A few approaches to verification of rendering tasks were shown along with the introduction of Concents, optional infrastructural component purposed with securing the network and allowing software developers to implement custom licensing logic
• Then Intel SGX technology was shown as a potentially good fit with regard to both nondeterministic verification and decentralization of Concent

SUMMARY

# Piotr janiuk

CTO, co-founder

Golem’s speaker at Devcon-0 and Devcon-1. Previously a designer and lead developer of Black Vision, a real-time rendering engine for TV broadcasting. Implemented the fastest (at the time) software jpeg2000 codec for DCP. Also took part in a few side projects related to p2p networks.

Interested in computer graphics, digital signal processing, cryptography, compilers, virtualization, blockchain tech, parallel computing, distributed computing, trustless computing and optimization techniques.

viggith@golem.network

# thank you

## www.golem.network

For the help with this presentation thanks to:

Substantial knowledge: Aleksandra Skrzypczak, Łukasz Gleń

Design: Jacek Muszyński, Urszula Trzaskowska (Cobaltblue)

Edit: Joanna Janiuk, Dan Horne