mirror of
https://github.com/Kindelia/Kind2.git
synced 2024-09-11 07:15:45 +03:00
Litereum.md fix: spelling, contractions, topic 5
This commit is contained in:
parent
5422437c62
commit
4589e55c74
@ -5,9 +5,9 @@ In 2013, the first smart-contract blockchain, Ethereum, was proposed, extending
|
||||
Bitcoin with a stateful scripting language that allowed arbitrary financial
|
||||
transactions to be settled without third parties. Notably, Ethereum's built-in
|
||||
virtual machine made it a general-purpose computer, even though most of the
|
||||
protocol's complexity wasn't required to achieve Turing completeness. Litereum
|
||||
protocol's complexity was not required to achieve Turing completeness. Litereum
|
||||
is a massive simplification of this concept, trading features for raw
|
||||
simplicity. Since it doesn't have a native token, it isn't a cryptocurrency
|
||||
simplicity. Since it does not have a native token, it is not a cryptocurrency
|
||||
itself, but currencies can be created as internal programs. In essence, Litereum
|
||||
is a peer-to-peer Lambda Calculus interpreter, making it a minimal decentralized
|
||||
computer, and a politically neutral smart-contract platform.
|
||||
@ -31,7 +31,7 @@ Having a simpler implementation has two major benefits.
|
||||
Since there is less code, the attack surface is narrower, making a full node
|
||||
much easier to audit. Moreover, the internal scripting language is prone to
|
||||
formal verification, further reinforcing security. This is only possible because
|
||||
it isn't based on stack machines, but on a simply-typed affine calculus that is
|
||||
it is not based on stack machines, but on a simply-typed affine calculus that is
|
||||
type-checked on-chain and has a clear cost model, preventing reentrancy attacks
|
||||
(that would lead to invalid states, hindering formal verification) and spam
|
||||
(which would be unavoidable in the usual lambda calculus, due to the
|
||||
@ -56,12 +56,12 @@ Below are some of the major differences that make this possible:
|
||||
|
||||
Ethereum uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for message
|
||||
authentication as a hard-coded algorithm that is part of the protocol. As of
|
||||
2021, it is still not possible to create Ethereum accounts that don't depend on
|
||||
2021, it is still not possible to create Ethereum accounts that do not depend on
|
||||
ECDSA signatures. Since ECDSA is vulnerable to quantum attackers, if a quantum
|
||||
computer of reasonable scale is developed, most Ethereum accounts will have
|
||||
their private keys exposed, which would be catastrophic to the network.
|
||||
|
||||
Litereum doesn't have a native account system or signature scheme. Instead,
|
||||
Litereum does not have a native account system or signature scheme. Instead,
|
||||
users create accounts by simply deploying smart-contracts that they control
|
||||
through their preferred authentication scheme. As such, users are free to use a
|
||||
cheaper, but less secure, signature algorithm, like ECDSA, or an expensive, but
|
||||
@ -75,7 +75,7 @@ not only has no "preferred currency", but it has no built-in currency at all: it
|
||||
is a pure computation network. Of course, users can still create their own
|
||||
tokens as contracts, but every internal currency is treated equally.
|
||||
|
||||
As a consequence, Litereum transactions don't have the "from", "to", "value",
|
||||
As a consequence, Litereum transactions do not have the "from", "to", "value",
|
||||
"gasPrice" or "gasLimit" fields. Instead, a transaction is just a block of code
|
||||
that is executed when mined in order to alter the blockchain state.
|
||||
Ethereum-like transactions can be emulated by a suitable script. For example,
|
||||
@ -97,10 +97,10 @@ same behavior as a classic Ethereum transaction.
|
||||
Like Ethereum, the computational cost of a transaction is measured in gas, and
|
||||
blocks have a size (space) and gas (time) limit. This keeps the cost of running
|
||||
a full node, both in terms of computation and storage cost, predictable. Since
|
||||
there isn't a native currency, there isn't a built-in gas-to-native-token
|
||||
there is not a native currency, there is not a built-in gas-to-native-token
|
||||
conversion either. Instead, a free market emerges, where users choose the exact
|
||||
amount of fees they want to pay, and miners select transactions that fit in a
|
||||
block, considering both space and computation costs, in a manner that maximies
|
||||
block, considering both space and computation costs, in a manner that maximizes
|
||||
their individual profits.
|
||||
|
||||
#### 3. A simpler block structure
|
||||
@ -115,7 +115,7 @@ patricia-merkle trees).
|
||||
Litereum takes a minimalistic approach: blocks store just the previous block,
|
||||
the nonce, the miner identity and a list of transactions (which are, themselves,
|
||||
just blocks of code). Of course, that means that features like light clients
|
||||
aren't possible, but we argue that these aren't used in practice: users either
|
||||
are not possible, but we argue that these are not used in practice: users either
|
||||
run full nodes, or trust someone that does.
|
||||
|
||||
#### 4. A simple concensus algorithm
|
||||
@ -134,20 +134,20 @@ Litereum's code.
|
||||
#### 5. It is slower
|
||||
|
||||
Finally, it must be stressed that Litereum is not designed to have a high layer
|
||||
1 throughput. It has a very limited block size and computation budget. This
|
||||
allows us to avoid design choices that would make it more scalable for the cost
|
||||
of added complexity. In general, Litereum should be less scalable than Ethereum
|
||||
on its layer 1.
|
||||
1 throughput. It has a very limited block size and computation budget. Thus, its
|
||||
complexity is reduced, but at the cost of being less scalable than Ethereum on
|
||||
its layer 1.
|
||||
|
||||
There are, though, key differences that make it better in some cases. For
|
||||
example, deploying contracts don't require signatures, and these are smaller
|
||||
than their Ethereum counterparts, due to shorter serialization and global
|
||||
sharing of functions. Deploying blocks and performing non-signed calls should be
|
||||
more scalable on Litereum.
|
||||
However, there are key differences that are a better fit for some scenarios.
|
||||
For example, the deployment of contracts does not require signatures; These
|
||||
contracts are smaller than their Ethereum counterparts for technical aspects
|
||||
such as shorter serializarion and global sharing of functions. Therefore,
|
||||
deploying blocks and performing non-signed calls should be more scalable on
|
||||
Litereum.
|
||||
|
||||
Regardless, we argue that layer 1 scalability is not the most important
|
||||
end-goal. Most layer 2 optimizations that make Ethereum more scalable apply to
|
||||
Litereum, so, a slower layer 1 won't detain long-term scalability.
|
||||
Litereum, so, a slower layer 1 will not detain long-term scalability.
|
||||
|
||||
Design
|
||||
------
|
||||
@ -249,7 +249,7 @@ A function has 6 fields:
|
||||
|
||||
A top-level command that alters the global state. Commands are grouped in pages.
|
||||
Tracing a parallel to conventional blockchains, a command is like a transaction,
|
||||
and a page is like a block. The main difference is that commands don't need to
|
||||
and a page is like a block. The main difference is that commands do not need to
|
||||
be signed. There are 4 variants of commands:
|
||||
|
||||
##### 1. `new_type(type)`
|
||||
@ -266,11 +266,11 @@ If the function's name already exists, then this command fails.
|
||||
|
||||
If the function's body is ill-typed with a type context initialized with the
|
||||
function's argument list, then this command fails. The function body
|
||||
is ill-typed if it doesn't pass the type-check procedure, with a type context
|
||||
is ill-typed if it does not pass the type-check procedure, with a type context
|
||||
initialized with each variable on the function's argument list.
|
||||
|
||||
If the function's body is invalid, then this command fails. The function body is
|
||||
invalid if it doesn't pass the validate procecure.
|
||||
invalid if it does not pass the validate procedure.
|
||||
|
||||
##### 3. `new_user(user)`
|
||||
|
||||
@ -286,10 +286,10 @@ If the signature is invalid, the command is executed anonymously, with the
|
||||
username being set as the empty bitstring.
|
||||
|
||||
If the expression's body is ill-typed, then this command fails. The function body
|
||||
is ill-typed if it doesn't pass the type-check procedure with an empty context.
|
||||
is ill-typed if it does not pass the type-check procedure with an empty context.
|
||||
|
||||
If the expression's body is invalid, then this command fails. The expression
|
||||
body is invalid if it doesn't pass the validate procedure.
|
||||
body is invalid if it does not pass the validate procedure.
|
||||
|
||||
#### Term
|
||||
|
||||
@ -302,7 +302,7 @@ Represents a variable bound by a global function, or by a pattern-matching
|
||||
clause. When a function is called, or a pattern-match takes place, the bound
|
||||
variable will be substituted by its called, or matched, value. Variables must be
|
||||
affine, which means the same bound variable can only be used at most once, and
|
||||
must be unique, which means the same name can't be bound to two different
|
||||
must be unique, which means the same name cannot be bound to two different
|
||||
variables, globally.
|
||||
|
||||
##### 2. `create(type, form, vals)`
|
||||
@ -325,7 +325,7 @@ A create variant is well-typed if:
|
||||
its type matches the type stored on `fields[i]`, where `fields` is the list
|
||||
of fields stored on the constructor of number `ctor` in the selected type
|
||||
|
||||
The create variant doesn't compute. It is irreducible.
|
||||
The create variant does not compute. It is irreducible.
|
||||
|
||||
##### 3. `match`
|
||||
|
||||
@ -410,11 +410,11 @@ type Lit.Cons.Page {
|
||||
}
|
||||
```
|
||||
|
||||
Unlike Bitcoin blocks, a LitCons page doesn't hold a set of transactions.
|
||||
Unlike Bitcoin blocks, a LitCons page does not hold a set of transactions.
|
||||
Instead, it stores an arbitrary blob of 1280 bytes of data. The size was chosen
|
||||
to allow a full block to fit in a small UDP packet, allowing for fast
|
||||
propagation. There are no "block headers": a page stores all its data. There
|
||||
aren't native tokens, nor transaction fees. The incentives to include Litereum
|
||||
are not native tokens, nor transaction fees. The incentives to include Litereum
|
||||
commands (transactions) in a page are determined by miners and users: fees can
|
||||
be paid with any internal token.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user