bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 3쪽 중 1쪽
The Golem Project
Crowdfunding Whitepaper
final version
November 2016
Table of contents
Overview of the Golem Project
Grand vision and core features
Golem as an Ecosystem
Supply of Infrastructure
Demand for Computing Resources
Software & Microservices
The first use case: CGI rendering
Long term vision: Golem as a building block of Web 3.0
Golem Network Token (GNT)
Application Registry
Transaction Framework
Resilience
Roadmap
Brass Golem
Clay Golem
Stone Golem
Iron Golem
Future integrations
Crowdfunding
Crowdfunding summary
Budget and levels of funding
Golem Team
Managers
Key developers
Developers
Business development and communication
Overview of the Golem Project
Grand vision and core features
●
Golem
is
the
first
truly
decentralized
supercomputer,
creating
a
global
market
for
computing
power.
Combined
with
flexible
tools
to
aid
developers
in
securely
distributing
and
monetizing
their
software,
Golem
altogether
changes
the
way
compute
tasks
are
organized
and
executed.
By
powering
decentralized
microservices
and
asynchronous
task
execution,
Golem
is
set
to
become
a
key
building
block
for
future
Internet
service
providers
and
software
development.
And,
by
substantially
lowering
the
price
of
computations,
complex
applications
such
as
CGI
rendering,
scientific calculation, and machine learning become more accessible to everyone.
●
Golem
connects
computers
in
a
peer-to-peer
network,
enabling
both
application
owners
and
individual
users
("requestors")
to
rent
resources
of
other
users’
("providers")
machines.
These
resources
can
be
used
to
complete
tasks
requiring
any
amount
of
computation
time
and
capacity.
Today,
such
resources
are
supplied
by
centralized
cloud
providers
which,
are
constrained
by
closed
networks,
proprietary
payment
systems,
and
hard-coded
provisioning
operations.
Also
core
to
Golem’s
built-in
feature
set
is
a
dedicated
Ethereum-based
transaction
system,
which
enables
direct payments between requestors, providers, and software developers.
●
The
function
of
Golem
as
the
backbone
of
a
decentralized
market
for
computing
power
can
be
considered
both
Infrastructure-as-a-Service
(IaaS),
as
well
as
Platform-as-a-Service
(PaaS).
However,
Golem
reveals
its
true
potential
by
adding
dedicated
software
integrations
to
the
equation.
Any
interested
party
is
free
to
create
and
deploy
software
to
the
Golem
network
by
publishing
it
to
the
Application
Registry.
Together
with
the
Transaction
Framework,
developers
can
also
extend
and
customize
the payment mechanism resulting in unique mechanisms for monetizing software.
Golem as an Ecosystem
Golem's
business
case
boils
down
to
the
fact
that,
due
to
relatively
recent
technological
advances,
the
market
for
computing
resources
can
be
organized
according
to
entirely
new
principles.
In
contrast,
the
compute
market
today
is
dominated
by
heavyweight
players
such
as
Amazon,
Google,
Microsoft
and
IBM,
who
leverage
their
market
power
and
assets
to
ensure
hefty
margins,
resulting
in
inefficiently
priced
compute
services.
Luckily,
the
market
is
not
doomed
to
function
this
way
forever.
With
Golem
the
supply
of
computing
resources
is
based
on
contributions
of
individual
and
professional
providers,
combined
with
an
array
of
dedicated
software
solutions
via
Golem’s
Application
Registry
–
itself
operating
on
a
single
and competitive market with nearly
complete information
market.
Scaling
the
compute
market
enabled
by
Golem
requires
onboarding
three
groups:
suppliers
of
computing
resources
("providers"),
task
creators
("requestors")
who
submit
their
tasks
to
be
computed
by
the
network,
and
of
course,
software
developers.
These
three
groups
comprise
Golem’s unique, interdependent ecosystem.
Group
Golem features
Incentive to participate
Requestors
Golem offers tools to execute
compute-intensive tasks.
Requestors get access to affordable and
scalable solutions, which combine hardware
and software.
Providers
Golem combines and utilizes
(almost) any kind of existing
computing hardware.
Hardware providers get paid for renting out
their hardware.
Software Developers
Golem is a flexible platform to
deploy and monetize software.
Software developers use Golem as a
distribution channel, associated with access
to hardware.
Supply of Infrastructure
The
supply
of
computing
power
to
the
network
comes
from
providers.
This
could
be
anyone,
from
an
individual
renting
out
idle
CPU
cycles
of
a
gaming
PC,
to
a
large
datacenter
contributing
their
entire
capacity.
Providers
have
the
incentive
to
join
Golem
because
they
receive
payments
from
requestors
for
the
completed
tasks.
Of
course,
Golem’s
user
interface
will
be
easy
to
use,
giving
providers
a
clear
way
to
set
prices
and
decide
what
fraction
of
their
own idle resources they are willing to rent out.
Demand for Computing Resources
In
order
to
reward
providers
for
contributing
their
resources,
Golem
needs
to
attract
requestors
seeking
additional
computing
resources.
The
market
Golem
creates
will
be
highly
competitive
due
to
nearly
complete
information,
and
the
ease
of
deploying
tasks
on
any
hardware.
This
will
not
only
make
using
Golem
simple,
which
will
attract
requestors
-
highly
competitive
setup
will
also
increase
efficiency
of
the
market,
very
likely
resulting
in
much
more
comprehensive
and
advantageous
pricing
compared
to
the
existing
cloud
computing
platforms.
One
important
feature
is
that
Golem's
marketplace
will
enable
requestors
to
become
providers:
because
most
of
them
will
need
additional
resources
only
occasionally.
They
will
be
able
to
rent
out
their
own
hardware
and
earn
extra
fees.
In
addition,
financial
aspects
are
not
going
to
be
the
sole
incentive
to
use
Golem:
one
of
its
key
features
will
be
the
availability
of diverse software running on the Golem network, accessible from the Application Registry.
Software & Microservices
Although
some
initial
use
cases
(such
as
CGI
rendering)
are
going
to
be
developed
and
implemented
by
the
Golem
team,
it
is
essential
to
engage
other
software
developers
to
develop
their
own
ideas
for
Golem
applications.
The
number
and
quality
of
such
applications
is
one
of
the
key
factors
in
Golem’s
future
success.
For
this
reason,
the
Application
Registry
and
Transaction
Framework
are
among
the
most
important
features
of
the
entire
ecosystem,
and
will
be
front
and
central
to
the
development
process.
Once
introduced,
they
will
provide
developers
with
flexible
and
efficient
tools
to
deploy,
distribute,
and
monetize
software
running
on
Golem.
This
is
going
to
be
a
perfect
solution
for
microservices
and
some
of
the
forthcoming
decentralized
applications
(DApps),
but
could
also
become
an
interesting
way
to
distribute existing proprietary and open source software.
The first use case: CGI rendering
Golem Alpha release: CGI rendering using Blender
It is public, follow
the link
to test Golem.
CGI rendering is the first
and very illustrative case
of real Golem usage. Rather
than using costly
cloud-based services or
waiting ages for one's own
machine to complete the
task, CGI artists can now
rent compute resources
from other users to render
an image quickly. The
payment from a requestor
(in this case, a CGI artist) is
sent directly to providers
who made their resources
available. In addition,
when the artist's machine
is idle, it can itself accept
tasks from other users.
Long term vision: Golem as a building block of Web 3.0
We
believe
the
future
Internet
will
be
a
truly
decentralized
network,
enabling
users
to
securely
and
directly
exchange
content,
without
sharing
it
with
corporations
or
other
middlemen.
Accordingly,
Golem
will
be
useful
not
only
to
compute
specific
tasks,
but
also
to
bulk-rent
machines
in
order
to
perform
operations
within
a
self-organizing
network.
Of
course,
this
will
require
the
simultaneous
development
of
other
technologies,
many
of
which
have gained significant traction in recent years.
Better
data-sharing
technologies
are
necessary,
but
taking
into
account
the
ongoing
development
of
IPFS/Filecoin
and
Swarm,
the
appropriate
solutions
seem
to
be
within
reach.
Eventually,
the
Ethereum
network
will
become
more
scalable,
more
efficient,
and
include
a
fully
functional
network
of
micropayment
channels.
Once
these
technologies
become
available,
it
is
easy
to
imagine
Golem
primarily
as
a
platform
for
microservices,
allowing
users
to
run
both
small
(e.g.
a
note-taking
app)
and
large
(e.g.
a
streaming
service)
applications
in
a
completely
decentralized
way.
Although
ambitious,
this
vision
seems
to
be
the
ultimate
argument for Golem’s long-term potential.
Golem Network Token (GNT)
The
Golem
Network
Token
("GNT")
account
is
a
core
component
of
Golem
and
is
designed
to
ensure
flexibility
and
control
over
the
future
evolution
of
the
project.
GNT
is
created
during
the
crowdfunding
period
(described
in
this
whitepaper)
and,
following
the
first
major
release
of Golem, GNT will be attributed a variety of functions in the Golem network.
●
Payments
from
requestors
to
providers
for
resource
usage,
and
remuneration
for
software developers is going to be exclusively conducted in GNT.
●
Once
the
Application
Registry
and
Transaction
Framework
are
implemented,
GNT
will
be
necessary
for
other
interactions
with
Golem,
such
as
submitting
deposits
by
providers
and
software
developers
or
participation
in
the
process
of
software
validation and certification (as described in the Application Registry section).
●
The
general
conditions
for
using
GNT
will
be
set
in
the
Transaction
Framework,
but
specific
parameters
of
these
interactions
will
be
possible
to
define
within
each
software integration.
The
supply
of
GNT
will
be
limited
to
the
pool
of
tokens
created
during
crowdfunding
period.
Creation of the GNT and initial GNT account functionalities
●
The
Golem
Network
Token
is
a
token
on
Ethereum
platform.
Its
design
follows
widely
adopted
token
implementation
standards.
This
makes
it
easy
to
manage
using existing solutions including Ethereum Wallet.
●
Maximum number of tokens created during crowdfunding period:
○
Total:
1 000 000 000 (100%)
○
Crowdfunding participants:
820 000 000 (82%)
○
Golem team
60 000 000 (6%)
○
Golem Factory GmbH
120 000 000 (12%)
●
Sending 1 ether to the GNT account will create 1 000 GNT
●
No token creation, minting or mining after the crowdfunding period.
●
Tokens will be transferable once the crowdfunding is successfully completed.
Go to the
crowdfunding section
to learn the details
and see how to support the Golem Project via crowdfunding.
Application Registry
The
Application
Registry
is
an
Ethereum
smart
contract,
to
which
anyone
can
publish
their
own
applications
that
are
ready
to
run
on
Golem
network.
The
goal
of
the
Application
Registry
is to:
●
Give
developers
a
way
to
publish
their
integrations
and
reach
out
to
users
in
a
decentralized manner;
●
Give requestors a place to look for specific tools fitting their needs;
●
Give providers full control over the code they run because of the security concerns.
Since
the
Golem
network
is
fully
decentralized,
we
also
want
the
Application
Registry
to
be
driven by the community.
Golem
allows
requestors
to
execute
the
code
of
an
application
on
someone
else's
computer.
This
code
is
sandboxed
and
executed
with
the
minimal
required
privileges.
But
software
bugs
are
everywhere,
and
once
in
a
while
people
defeat
sandboxes,
manage
to
execute
malicious
code
on
a
host
machine,
and
sometimes
even
take
it
over.
That’s
why
we
can't
rely
only
on
sandboxing.
We
could
try
to
automatically
evaluate
whether
or
not
the
code
is
safe,
but
this
is
literally
impossible
(
vide
halting
problem).
The
process
of
code
review
and
validation
cannot
be
fully
automated
and
left
to
the
autonomous
network.
On
the
other
hand,
it
is
impossible
to
assume that no one will ever publish malicious software to run on top of Golem network.
We
solve
these
problems
by
splitting
Application
Registry
users
into
three
categories:
authors,
validators
and
providers.
Authors
publish
applications,
validators
review
and
certify
applications
as
safe
and
trustworthy
by
adding
them
to
their
own
whitelist.
Validators
may
also
mark
applications
as
malicious
by
adding
them
to
their
own
blacklists.
Providers
are
also
given
the
right
to
choose
whom
to
trust
by
selecting
validators
whose
lists
are
used
by
the
particular
instance
of
Golem
running
on
their
nodes.
Apart
from
that,
providers
may
maintain
their
own
whitelists
or
blacklists.
This
gives
each
provider
a
lot
of
flexibility
in
deciding
exactly
what
software
to
run,
and
what
amount
of
work
to
put
into
software
curation.
What
is
more,
this
system
does
not
exclude
any
party,
and
there
is
always
room
for
new
validators
to
emerge.
By
default
Golem
runs
using
a
whitelist
of
trusted
applications.
Since
an
empty
whitelist
is
a
problem
for
someone
just
trying
Golem
out
for
the
first
time,
we
will
add
a
number
of
verified
entries
to
the
whitelist
as
a
part
of
the
initial
distribution.
A
provider
can
take
advantage
of
this
mechanism,
managing
her
own
whitelist,
or
simply
using
whitelists
of
validators
she
trusts.
On
the
other
hand,
a
provider
running
a
computing
farm
may
wish
to
rely
entirely
on
blacklists.
This
is
an
option
tailored
for
administrators
of
dedicated
machines,
who
want
to
maximize
their
profits
and
who
are
willing
to
ride
the
bleeding-edge.
In
this
scenario,
a
blacklist
is
used
to
banish
any
known
troublemaking
applications.
Again,
the
provider
can
maintain her own blacklist, or use the blacklists of validators she trusts.
Transaction Framework
When
creating
something
new
and
exciting,
it’s
hard
if
not
impossible
to
predict
all
the
opportunities
which
the
new
artifact
will
suddenly
make
possible.
Golem
is
a
generalized
global
supercomputer,
and
as
such,
it
will
no
doubt
find
its
niche
with
vastly
varied
applications.
They
might
need
very
diverse
remuneration
models.
We
are
not
able
to
design
a
one-size-fits-all
payment
system
for
Golem,
nor
will
we
attempt
to
force
one
upon
application
authors.
When
a
developer
integrates
her
application
with
Golem,
she
has
the
freedom
to
decide
which
transaction
model
she
implements,
as
long
as
it
is
compliant
with
Golem's
Transaction
Framework.
The
Transaction
Framework
will
take
the
form
of
a
set
of
requirements
to
follow;
basic requirements may include:
●
Entry in the Application Registry;
●
Use of open source and/or deterministic environment, such as EVM;
●
Community approval or rating of transaction model;
●
Use of GNT for remunerating software and resource providers.
We
are
building
the
transaction
framework
on
top
of
Ethereum.
Ethereum
gives
us
expressive
power, which is much-needed when implementing advanced, trustless schemes.
Example transaction framework components:
●
Diverse payout schemes such as
nanopayments
,
batching
●
Off-chain payment channels
●
Custom receipts
●
Payment to software developer
●
Per-unit use of software (per-node, per-hour, etc.)
In
the
future,
this
might
evolve
into
community-reviewed
template
code
to
be
used
in
the
implementation of custom transaction models.
It
is
also
possible
to
introduce
more
sophisticated
components
into
the
transaction
model
design, to meet specific goals not related to payments. For example:
●
Requestor
escrow
for
tasks
where
a
higher
level
of
commitment
is
required
(high
price
because
of
specialized
hardware
or
long
running
subtasks);
the
requestor
may
create a two-party escrow account and require providers to take part in it.
●
Provider
deposit:
the
requestor
may
require
to
be
in
control
of
some
amount
of
timelocked GNT.
●
Requestor
deposit:
the
provider
may
accept
tasks
only
from
requestors
who
are
in
control of some amount of timelocked GNT.
●
Registration
of
a
task
as
an
anchor
for
a
TrueBit-style
conflict
resolution
fallback
mechanism.
Resilience
Golem
is
a
fully
decentralized,
open
source
P2P
network
which
is
resilient
to
censorship,
and
free from a single point-of-failure.
Consensus
is
important
for
resilience
and
is
another
reason
why
Ethereum
is
utilized
for
transactions,
as
well
as
replicating
some
shared
state
and
metadata.
Golem
tasks
rely
on
integrity
and
consensus
mechanisms
for
deployment,
task
execution,
validation,
and
transactions.
Naturally,
Golem
inherits
Byzantine
fault
tolerance
properties
from
Ethereum.
For
task
execution
and
validation,
Golem
will
initially
rely
on
redundant
validation
and
Ethereum
state.
As
research
and
development
progresses,
optimizations
will
be
implemented
to
reduce
costs,
increase
throughput,
and
improve
resilience.
Optimisations
will
result
in
improvements
of
integrity
and
consensus
validation
schemes,
P2P
network
formation,
asynchronous transactions, and off-chain state transitions.
The
Golem
P2P
network
will
be
built
on
a
continuation
of
the
devp2p
protocol
series,
which
was
spearheaded
at
the
Ethereum
Foundation,
and
which
will
see
improvements
in
confidentiality,
robustness,
latency,
modularity,
and
the
inclusion
of
pertinent
libp2p
and
IPFS
standards.
Additional means to achieve resilience:
●
Signed
and
encrypted
messages
inside
the
Golem
network
ensure
authenticity,
which
protects against man-in-the-middle attacks and passive data collection.
●
Computation
takes
place
in
isolated
environments
with
minimal
privileges
and
lack
of
external network connectivity.
●
Whitelist
and
blacklist
mechanisms
allow
providers
to
build
trust
networks
and
run
only
applications prepared by trusted developers.
●
Reputation
system
helps
to
detect
malicious
node
and
mitigate
them
and
additionally
evaluates metrics to assist in secure, efficient and correct task routing.
●
Together,
the
application
registry
and
transaction
framework
mitigates
Sybil
and
whitewashing
attacks
by
providing
an
incentive
to
participate,
introducing
an
economic
and
computational
cost
to
participation,
and
providing
a
metric
for
reputation in order to maintain optimal connectivity.
●
The
Ethereum
integration
and
transaction
framework
makes
possible
custom
payment-based
security
mechanisms,
eg.
escrows,
deposits,
insurance
and
audit
proofs.
●
Security audits will be conducted for every release, performed by external contractors.
Roadmap
In
this
section
we
present
planned
milestones
for
Golem
development.
You
will
find
a
nontechnical
description
of
Golem’s
architecture
in
this
post
on
our
blog,
some
thoughts
about challenges ahead
here
and of course you can examine the code on
GitHub
.
The
successive
versions
of
Golem’s
software
are
split
into
milestones.
This
plan
should
be
considered
preliminary,
as
Golem
is
using
bleeding-edge
technologies,
and
is
itself
a
very
complex
project.
Each
milestone
should
be
preceded
with
research,
with
results
described
in
technical
whitepapers.
At
every
stage
new
functionalities
are
added,
but
the
scope
of
deliverables
at
every
milestone
depends
on
the
level
of
funding
raised.
In
the
description
of
milestones
presented
below,
these
functionalities
have
been
assigned
to
four
indicative
funding
scenarios:
(1)
are
implemented
regardless
of
the
level
of
funding,
while
with
(2),
(3)
and (4) will be implemented if the adequate
level of funding
is reached.
We
have
codenamed
concurrent
versions
of
Golem
using
descriptions
from
the
long
list
of
D&D’s golems
. The analogs might not be perfect, but these are e-golems after all.
Go-to-Market Strategy
For
every
milestone
there
is
a
corresponding
Go-to-Market
Strategy
(GMS).
Each
of
them
is
focused
on
value
propositions
developed
in
respective
milestones
and
specific
needs
of
Golem’s
ecosystem:
software
developers, requestors and providers.
●
In
the
long
run,
software
developers
are
pivotal
elements
of
the
GMS,
especially
starting
from
the
Stone
release
onwards
.
With
Golem
architecture
being
mature
enough
to
allow
developer프로젝트로 돌아가기
