Skip to content

Commit 9c6e404

Browse files
committed
Doc fixes and tidying
1 parent e2070c3 commit 9c6e404

File tree

2 files changed

+17
-10
lines changed

2 files changed

+17
-10
lines changed

docs/overview/convex-whitepaper.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
title: White Paper
2+
title: Convex White Paper
33
authors: [convex]
44
tags: [convex, technology]
55
permalink: white-paper
@@ -315,7 +315,7 @@ Convex eschews the idea of selecting a leader. We maintain the principle that **
315315
- Blocks can be **independent of all previous Blocks** - they do not necessarily form a "chain" linked by cryptographic hashes.
316316
- 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. ??????.
317317

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).
319319

320320
#### Convergent Consensus
321321

@@ -338,9 +338,9 @@ The Ordering of one or more other peers could be removed by from the Belief of a
338338

339339
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.
340340

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.
342342

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.
344344

345345
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`:
346346

@@ -772,7 +772,7 @@ The CVM therefore constrains **time**, **space** and **depth**.
772772

773773
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.
774774

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.
776776

777777
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.
778778

@@ -1054,15 +1054,15 @@ Memory Consumption is computed at the end of each transaction, and is defined as
10541054

10551055
`Memory Consumption = [CVM State Size at end of Transaction] - [CVM State Size at start of Transaction]`
10561056

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
10581058

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:
10601060

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
10621062
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.
10631063
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
10641064

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.
10661066

10671067

10681068
#### Allowance transfers
@@ -1077,7 +1077,7 @@ It is permissible to make an allowance transfer directly between accounts. This
10771077

10781078
#### Actor Considerations
10791079

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.
10811081

10821082
One exception to this is with scheduled execution, where an actor itself may be the origin for a transaction.
10831083

docs/products/convex-desktop/index.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,10 @@
1+
---
2+
title: Convex Desktop
3+
authors: [convex]
4+
tags: [convex]
5+
sidebar_position: 0
6+
---
7+
18
# Convex Desktop
29

310
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

Comments
 (0)