Skip to content

Commit 347454f

Browse files
Christian-MKChristian-MK
committed
adds milestone2 content to staking & consensus and the economic model md
1 parent 4edbb7a commit 347454f

File tree

3 files changed

+320
-10
lines changed

3 files changed

+320
-10
lines changed

‎docs/project-catalyst/f12-consensus.md

+12-5
Original file line numberDiff line numberDiff line change
@@ -49,11 +49,18 @@ Koch, 2024)][consensus-paper]
4949

5050
## Milestone 2
5151

52-
Orcfax will produce the following:
53-
54-
- economic model report
55-
- use case descriptions
56-
- network architecture diagrams
52+
After the successful completion of milestone 1 and its research objectives, work
53+
on the consensus PoC can begin; however, a number of considerations must be be
54+
assessed which are quite impactful on design. Some of these consideration are
55+
economical.
56+
57+
As Orcfax prepares to for milestone 3 which will conclude with the completion of
58+
a consensus PoC, we have documented the economic considerations and their
59+
relationship to our other proposal (i.e. implementing a staking mechanism); our
60+
findings are made available [here][m2-1] along with a use case description, and
61+
diagrams where appropriate.
62+
63+
[m2-1]: ./f12-economic-model.md
5764

5865
## Milestone 3
5966

‎docs/project-catalyst/f12-economic-model.md

+296
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,296 @@
1+
---
2+
sidebar_class_name: hidden
3+
---
4+
5+
# EchoNet: considerations for the economy of a decentralized network
6+
7+
# Context
8+
9+
A decentralized service is a service provided by a set of separate autonomous
10+
participants that are not subject to a hierarchy. Of the network of
11+
participants, the majority share a common purpose of providing a good service.
12+
However, some participants may be incompetent or even have malign intent. This
13+
network of mutually suspicious participants must coordinate the running of a
14+
distributed service.
15+
16+
Part of an overall design of such a system is providing tooling which enables
17+
them to reach agreement over various network related tasks; this is consensus.
18+
The design must also ensure that participants in that process are rewarded for
19+
the good service they provide and are strongly discouraged from behaving badly;
20+
staking is the term we use to encapsulate the process governing this aspect of a
21+
decentralized service.
22+
23+
The following will seek to assess the economic implications for Orcfax as it
24+
continues research and development into maturing its decentralized network of
25+
validator nodes, known as EchoNet, through the integration of staking and
26+
consensus mechanisms. Where necessary, specific considerations relating to
27+
staking and consensus in terms of economic impacts will be addressed separately.
28+
29+
## Use cases
30+
31+
Projects which may benefit from the catalyst project deliverables, from either
32+
consensus or staking, may be any which require a set of participants to provide
33+
a service on behalf of the project in a decentralized manner; the design of the
34+
consensus and staking proof of concepts continue to be executed in such a way
35+
that while in context of this proposal, the service provision is an oracle, it
36+
need not be as this aspect is off-chain.
37+
38+
The deliverables from these projects have broad utility and may be used by
39+
projects offering diverse services to their users.
40+
41+
### Specific considerations for Staking
42+
43+
Projects assessing the implementation of a decentralized network may assume that
44+
most participants will be honest and competent, and that they will continue to
45+
participate honestly and with competence providing participation is
46+
straightforward and financially neutral. However, they are without hierarchy or
47+
a priori obligation to provide this service or cooperate with one another.
48+
49+
This is why the output system must provide the incentive structure that, under
50+
these assumptions, will result in good service provision.
51+
52+
A participant's behaviour is accounted for: good behaviour that aids the quality
53+
of service provision is measured, as is bad behaviour. We can assume that the
54+
participants are able to reach consensus on these accounts and produce a
55+
signature/signatures as proof of general acceptance. This happens periodically -
56+
say once every 24 hours.
57+
58+
The rewards are paid out from a 'treasury' and forfeit funds are paid to the
59+
treasury. The currency is a native asset. The project output should include the
60+
scripts governing these aspects of the treasury. Other funding of the treasury
61+
is beyond project scope. We will assume the treasury is sufficiently funded to
62+
meet the burden of conveying rewards.
63+
64+
## Staking
65+
66+
Orcfax is an aspiring decentralized Oracle service. To participate within the
67+
network, a participant must be in possession of two types of Cardano native
68+
assets:
69+
70+
One Orcfax Validator License, one of 100 NFTs At least 500,000 \$FACT
71+
72+
Participants are strongly discouraged from behaving badly through the use of
73+
slashing. A participant must first put 'at stake' some asset(s). If the
74+
participant's actions are deemed bad, some or all of their assets are forfeit
75+
through a slashing mechanism.
76+
77+
To incentivize good behavior, a participant receives rewards proportionate to
78+
their good service.
79+
80+
However, when balancing incentives and penalties for participants care must be
81+
taken. The wrong incentive structure may either:
82+
83+
cause a race to the top. Rewards only go to a few participants. Eventually this
84+
leads to centralization which degrades robustness. cause a race to the bottom.
85+
Participants are rewarded even if they are poor service providers.
86+
87+
Both are bad for the long term health of the service.
88+
89+
### Components overview
90+
91+
There are the following key components of the consensus PoC:
92+
93+
1. Constitution - holds the signing key.
94+
1. Hold - rewards awaiting collection.
95+
1. Safe - locks a participants funds.
96+
1. Treasury - holds funds awaiting dispensing.
97+
1. Dispenser - manages the dispensing of rewards.
98+
99+
#### The Constitution
100+
101+
The constitution holds any dynamic data required by the protocol. This is a
102+
simple, classic design consisting of a multipurpose script with spend and mint
103+
purpose. The script is seeded so that it can only be initiated once.
104+
105+
A validity token (NFT) is locked at the script, its utxo's inlined datum
106+
contains the pubkey. It can be spent only if the pubkey signs the transaction.
107+
108+
If the tokens are not burnt in the transaction, then the validity token must be
109+
output to the same address.
110+
111+
#### The Safe
112+
113+
The safe holds participants' funds. These are at risk if the participant is
114+
deemed to behave badly. It is also required to claim rewards.
115+
116+
A participant locks funds in (an instance of) a **safe**. While it exists, it is
117+
represented on the L1 tip by a single utxo.
118+
119+
```mermaid
120+
---
121+
title: Safe lifecycle
122+
---
123+
stateDiagram-v2
124+
[*] --> Locked : lock
125+
Locked --> Locked : update
126+
Locked --> Renounced : renounce
127+
Renounced --> [*] : free
128+
Locked --> [*] : slash
129+
Renounced --> [*] : slash
130+
```
131+
132+
This is the basic lifecycle of a safe.
133+
134+
First, participants take part in a decentralized key generation (DKG) process.
135+
The output of the DKG is one key pair for each participant as well as a single
136+
collective pubkey. The signature generation procedure requires multiple
137+
coordinated rounds. We'll call this the 'signature dance'. The output of the
138+
signature dance is a single signature. On-chain verification of the signature
139+
with the collective pubkey is indistinguishable from that of a 'vanilla'
140+
signature.
141+
142+
We may assume that off-chain, the participants are able to organise a DKG, and
143+
will organise FROST style signing of the rewards and slashing data. Each
144+
individual pubkey can then be used to identify the participant. The collective
145+
pubkey is used to verify the signature.
146+
147+
If the participant is satisfied with the DKG step they perform a `lock` step.
148+
This initialises the safe. It is now `Locked` with the owners keys in the datum.
149+
150+
While `Locked` the owner may `update` the safe with new keys.
151+
152+
If the participant wishes to no longer participate, they `renounce`. The safe is
153+
now `Renounced`.
154+
155+
All participants should be watching the chain for `renounce` actions, as they
156+
should no longer accept signatures associated with the renouncer. The `renounce`
157+
begins a limited period of time where the other participants can still apply
158+
penalties.
159+
160+
Once this time period has elapsed, the participant may `free` their locked
161+
funds. All funds are again at the participants disposal.
162+
163+
If sufficient participants deem a participant with either a `Locked` or
164+
`Renounced` safe to have acted badly, they can produce a slash transaction. This
165+
empties the contents of the safe into the treasury. The script ensures this is
166+
permitted only when signed by the constitution.
167+
168+
#### The Hold
169+
170+
The `Hold` is a simple script which "holds" rewards until they are claimed.
171+
172+
A utxo at the `Hold` address has an inline datum indicating to which safe owner
173+
it belongs.
174+
175+
##### The Dispenser
176+
177+
The dispenser facilitates the dispensing of rewards to the `Hold`.
178+
179+
## Consensus
180+
181+
The economics of consensus look quite different. The focus here is in
182+
understanding the cost of validator participation, the cost to a validator when
183+
slashed, and the potential benefits of performing maliciously. If the potential
184+
profit of providing bad information outweighs the cost, validator nodes would be
185+
financially advantageous to act badly and there would be significant risk to
186+
network integrity.
187+
188+
At the time of this writing, the cost of acquiring 500,000 FACT tokens is
189+
approximately 5,025 ADA or 5,577 USD. The floor price for a Orcfax Validator
190+
License is 10,500 ADA or 11,653 USD. This means that the cumulative stake
191+
required to participate has a value of approximately 17,230 USD.
192+
193+
In order to combat the risks associated with validators having financial
194+
advantage to act badly, Orcfax is tasked with devising a strategy by which
195+
malicious behavior becomes cost prohibitive or disadvantageous. However, at this
196+
stage of research and development, Orcfax has not yet decided on the process
197+
through which consensus will be reached over a given fact statement; the
198+
different ways this might be orchestrated have implications on how malicious
199+
behavior may need to be addressed. For this reason, we will explore two options:
200+
1.) where one node proposes a statement, and a subset of the 100 nodes within
201+
the network verifies that statement; 2.) where all nodes within a randomly
202+
selected subset propose a statement, and the median entry is selected.
203+
204+
In the first, where a proposer has their statements verified by a subset of n
205+
nodes, then the cost of the lie (using the values given above) becomes
206+
$n * 17,230$ USD. So, in a system where the threshold for verification was 10
207+
nodes, then the cost of the lie is more than 170,000 USD.
208+
209+
However, if instead of requiring any subset for verification we had the n nodes
210+
selected at random, then the lie becomes significantly more expensive as even If
211+
the bad actor corrupted 10 of the total 100 nodes, it would be very unlikely
212+
those 10 would be randomly selected.
213+
214+
In the second where a subset of nodes is randomly selected, each proposes a
215+
statement, and the median is selected, then the cost of the lie at a minimum is
216+
$((n + 1) / 2) * 17,230$ USD or the value of half the selected nodes +1. So in a
217+
case where, from 100 nodes, a subset of 21 are selected at random, the cost of
218+
the lie would be nearly 190,000 USD.
219+
220+
But again, the fact that this subset of nodes is selected at random means that
221+
these costs are the minimum. Even with a bad actor having at least 11 licenses,
222+
and the corresponding fact, the probability of them all being selected to
223+
propose within the subset is very slim.
224+
225+
For either of the above scenarios, the value of \$FACT and cost of acquiring a
226+
Validator License have immense impact on the appropriate size of the subset of
227+
nodes; It could very well be that, using the values given previously, it's
228+
necessary to select a subset of 21 (or more) nodes in order to adequately reduce
229+
the risk of bad actors and to make bad data cost prohibitive. However, this
230+
narrative dramatically changes should \$FACT halve in value, or increase 10x.
231+
232+
These are all considerations thatOrcfax must weigh as we continue to develop a
233+
consensus solution.
234+
235+
## Participation costs
236+
237+
Participants will need to shoulder the cost of either acquiring their own
238+
equipment by which they will participate in the network, or the cost of
239+
maintaining a subscription to cloud infrastructure. While the cost of
240+
implementing the software responsible for consensus and staking is unknown at
241+
this time, the current cost of running a mainnet node within the Orcfax
242+
federated network is approximately 200 USD per month, which should serve as a
243+
basic understanding of costs for network participants; its important to
244+
understand that this approximation of cost is an estimate and may not reflect
245+
the total cost of participation for validators.
246+
247+
:::info[N.B.]
248+
249+
The cost of implementing and running staking and consensus mechanisms remains
250+
unknown because design choices relating to either can have significant impacts.
251+
This section will be updated after the next milestone and the completion of the
252+
PoC's.
253+
254+
:::
255+
256+
## Rewards
257+
258+
Early on in Orcfax development, we established the mechanisms by which
259+
Validators would be onboarded and rewarded for their participation in the
260+
network. Our [tokenomics][r-1] ensured that the biggest allocation of \$FACT was
261+
reserved to reward our decentralized validators for running Orcfax nodes.
262+
263+
Initially, with a relatively low number of integrators, validators will be
264+
rewarded for their participation in the network with \$FACT from the [Validator
265+
Rewards Allocation][r-2], which contains 50% of the total FACT token supply, or
266+
500,000,000 (50%) \$FACT.
267+
268+
The amount of FACT tokens rewarded from this allocation per publication will
269+
decrease over time. As more consumers start using Orcfax oracle feeds, the
270+
increasing \$FACT payments from these customers will compensate for the reduced
271+
emission from the Validator Rewards Allocation, and will eventually replace them
272+
completely.
273+
274+
The following demonstrates how having integrators pay for feeds in FACT (or ADA)
275+
creates a positive feedback loop and buy pressure for \$FACT. The generated
276+
\$FACT payments from integrators are then distributed to entities crucial for
277+
network operation like Orcfax Validators.
278+
279+
![Orcfax Economic Model](/img/2024-09-17--orcfax-economic-model.png)
280+
281+
[r-1]: docs/fact-token/tokenomics.md
282+
[r-2]: docs/fact-token/tokenomics.md#validator-rewards
283+
284+
## Beyond the PoC
285+
286+
While research for both consensus and staking was completed within budget,
287+
systems analysis and development have, to date, exceeded initial estimates; this
288+
has largely been due to complexities which while foreseen, their scope was not
289+
entirely appreciated. The difference between the budget and actual costs is
290+
being covered by Orcfax.
291+
292+
Going forward, the reality of these cost discrepancies is useful for better
293+
understanding the real cost of any work which may be needed after the successful
294+
completion of catalyst closeout to move both the consensus and staking PoC’s
295+
towards mature software and beyond with the integration of consensus and staking
296+
mechanisms into EchoNet.

‎docs/project-catalyst/f12-staking.md

+12-5
Original file line numberDiff line numberDiff line change
@@ -45,11 +45,18 @@ Koch, 2024)][staking-paper]
4545

4646
## Milestone 2
4747

48-
Orcfax will produce the following:
49-
50-
- Economic model report
51-
- Use case descriptions
52-
- Network architecture diagrams
48+
After the successful completion of milestone 1 and its research objectives, work
49+
on the staking PoC can begin; however, a number of considerations must be be
50+
assessed which are quite impactful on design. Some of these consideration are
51+
economical.
52+
53+
As Orcfax prepares to for milestone 3 which will conclude with the completion of
54+
a staking PoC, we have documented the economic considerations and their
55+
relationship to our other proposal (i.e. implementing a consensus mechanism);
56+
our findings are made available [here][m2-1] along with a use case description,
57+
and diagrams where appropriate.
58+
59+
[m2-1]: ./f12-economic-model.md
5360

5461
## Milestone 3
5562

0 commit comments

Comments
 (0)