You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/overview/convex-whitepaper.md
+10-10Lines changed: 10 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: White Paper
2
+
title: Convex White Paper
3
3
authors: [convex]
4
4
tags: [convex, technology]
5
5
permalink: white-paper
@@ -315,7 +315,7 @@ Convex eschews the idea of selecting a leader. We maintain the principle that **
315
315
- Blocks can be **independent of all previous Blocks** - they do not necessarily form a "chain" linked by cryptographic hashes.
316
316
- It is possible for multiple Peers to propose Blocks **concurrently** for inclusion in consensus at the same time. This removes a major bottleneck compared to systems that require on some form of sequential leadership e.g. ??????.
317
317
318
-
An Ordering includes all Blocks up to the current Consensus Point. A Peer may propose a novel Block for consensus by appending it to the Ordering plus additional Blocks remaining to be confirmed in consensus.
318
+
An ordering includes all blocks up to the current consensus point. A peer may propose a novel block for consensus by appending it to the ordering (alongside any other additional blocks still to be confirmed in consensus).
319
319
320
320
#### Convergent Consensus
321
321
@@ -338,9 +338,9 @@ The Ordering of one or more other peers could be removed by from the Belief of a
338
338
339
339
During the convergence process conflicts in proposed block Orderings from different Peers are resolved by a system of convergent stake-weighted voting. [A diagram would be really helpful here] At each belief merge step, peers compute the total share of stake voting for each proposed block in the next position after the current Consensus Point. Peers have a view of the Orderings proposed by all other Peers.
340
340
341
-
Stake-weighted voting is applied iteratively to future proposed blocks, but only counting the votes by peers that have supported the winning ordering up to this point. Supporting a minority block causes peers to be temporarily excluded from the considered vote in following blocks. Peers that vote for orderings inconsistent with the majority cannot influence the ordering of any subsequent blocks.
341
+
Stake-weighted voting is applied iteratively to future proposed blocks, but only counting the votes by peers that have supported the winning ordering up to this point. Supporting a minority block causes peers to be temporarily excluded from the vote on following blocks. Peers that vote for orderings inconsistent with the majority cannot influence the ordering of any subsequent blocks. There is therefore an incentive for peers to adopt an ordering consistent with the majority.
342
342
343
-
Once the overall winning ordering has been determined, any peer can append any new Blocks it wishes to propose, adopting this ordering as its own proposal. This ordering is signed and incorporated into the pPeer's own belief, which is then propagated onwards to other peers.
343
+
Once the overall winning ordering has been determined, any peer can append any new blocks it wishes to propose, adopting this ordering as its own proposal. This ordering is signed and incorporated into the peer's own belief, which is then propagated onwards to other peers.
344
344
345
345
As an illustration, consider three Peers that are initially in consensus with respect to an ordering of blocks `XXXX` but peers `A` and `B` propose new blocks `Y` and `Z`:
346
346
@@ -772,7 +772,7 @@ The CVM therefore constrains **time**, **space** and **depth**.
772
772
773
773
Convex constrains time by placing a "juice cost" on each CVM operation performed. Any transaction executed has a "juice limit" that places a bound on the total amount of computational work that can be performed within the scope of the transaction.
774
774
775
-
The originating account for a transaction must reserve juice by paying an amount `[juice limit] x [juice price]` at the start of the transaction. Any unused juice at the end of the transaction is refunded at the same rate. The juice price a dynamically varying price that adjusts with amount of execution performed per unit time by the Convex network as a whole: this is a cryptoeconomic mechanism to disincentivise transactions from being submitted at peak periods, and as a protection from DoS attacks by making it prohibitively expensive to flood the compute capacity of the network for a sustained period of time.
775
+
The originating account for a transaction must reserve juice by paying an amount `[juice limit] x [juice price]` at the start of the transaction. Any unused juice at the end of the transaction is refunded at the same rate. The juice price is a dynamically varying price that adjusts with the amount of load on the Convex network as a whole: this is a cryptoeconomic mechanism to disincentivise transactions from being submitted at peak periods, and as a protection from DoS attacks by making it prohibitively expensive to flood the compute capacity of the network for a sustained period of time.
776
776
777
777
If the juice limit has been exceeded, the CVM terminates transaction execution with an exception, and rolls back any state changes. No juice is refunded in such a situation - this penalises users who attempt excessive resource consumption either carelessly or maliciously.
778
778
@@ -1054,15 +1054,15 @@ Memory Consumption is computed at the end of each transaction, and is defined as
1054
1054
1055
1055
`Memory Consumption = [CVM State Size at end of Transaction] - [CVM State Size at start of Transaction]`
1056
1056
1057
-
If a transaction has zero Memory Consumption, it will complete normally with no effect from the Memory Accounting subsystem
1057
+
If a transaction has zero memory consumption, it will complete normally with no effect from the memory accounting subsystem
1058
1058
1059
-
If a transaction would complete normally, but has a positive Memory Consumption, the following resolutions are attempted, in this order:
1059
+
If a transaction would complete normally, but has a positive memory consumption, the following resolutions are attempted, in this order:
1060
1060
1061
-
1. If the user has sufficient Allowance, the additional memory requirement will be deducted from the allowance, and the transaction will complete normally
1061
+
1. If the user has sufficient allowance, the additional memory requirement will be deducted from the allowance, and the transaction will complete normally
1062
1062
2. If the transaction execution context has remaining juice, and attempt will be made to automatically purchase sufficient memory from the Memory Exchange. The maximum amount paid will be the current juice price multiplied by the remaining juice for the transaction. If this succeeds, the transaction will complete successfully with the additional memory purchase included in the total juice cost.
1063
1063
3. The transaction will fail with a MEMORY Error, and any state changes will be rolled back. The User will still be charged the juice cost of the transaction
1064
1064
1065
-
If a transaction has negative Memory Consumption, the memory allowance of the user will be increased by the absolute size of this value. In effect, this is a refund granted for releasing storage requirements.
1065
+
If a transaction has negative memory consumption, the memory allowance of the user will be increased by the absolute size of this value. In effect, this is a refund granted for releasing storage requirements.
1066
1066
1067
1067
1068
1068
#### Allowance transfers
@@ -1077,7 +1077,7 @@ It is permissible to make an allowance transfer directly between accounts. This
1077
1077
1078
1078
#### Actor Considerations
1079
1079
1080
-
All Accounts, including actors, have a memory allowance. However, in most cases actors have no use for a memory allowance: any memory consumed during interaction with an actor will be accounted for via the user account account that originated the transaction.
1080
+
All Accounts, including actors, have a memory allowance. However, in most cases actors have no need for a memory allowance: any memory consumed during interaction with an actor will be accounted for via the user account account that originated the transaction.
1081
1081
1082
1082
One exception to this is with scheduled execution, where an actor itself may be the origin for a transaction.
Copy file name to clipboardExpand all lines: docs/products/convex-desktop/index.md
+7Lines changed: 7 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,10 @@
1
+
---
2
+
title: Convex Desktop
3
+
authors: [convex]
4
+
tags: [convex]
5
+
sidebar_position: 0
6
+
---
7
+
1
8
# Convex Desktop
2
9
3
10
Convex Desktop is a GUI tool for interacting with Convex. Designed for developers and power users, it puts all the capabilities of Convex at your fingertips.
0 commit comments