Kindelia/Kind2
1
1
Fork 0
mirror of https://github.com/Kindelia/Kind2.git synced 2024-09-11 07:15:45 +03:00
Code Issues Projects Releases Wiki Activity

Wall of Litereum text

Browse Source
This commit is contained in:
MaiaVictor 2021-09-23 16:20:15 -03:00
parent 522453de94
commit 4c07155ee4
1 changed files with 167 additions and 111 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

278
base/Lit/Litereum.md
View File

@ -6,29 +6,177 @@ 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
is a massive simplification of this concept, trading features for simplicity.
Without a native token, it, technically, isn't a cryptocurrency, even though
tokens can be created internally as stateful programs. In essence, Litereum is
just the Lambda Calculus running in a peer-to-peer network, making it a
politically neutral decentralized computer.
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
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.
Introduction
------------
Litereum's design and implementation is, essentially, a massively distillation
of Ethereum, taking away all the complex features that are either historical
artifacts or optimizations, and keeping only the bare minimum required to
establish a decentralized computer and smart-contract platform. For comparison,
our reference Python full node requires about **3000 lines of code**, while the
standard Ethereum full node has <TODO>.
### Why keep it so simple?
Having a simpler implementation has two major benefits.
#### 1. Litereum is secure
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
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
impossibility of measuring the cost of a beta-reduction).
#### 2. Litereum is apolitical
Ethereum's complexity makes it politically centralized in the hands of the few
developers that fully understand the protocol. While this is fine for most
common users, big companies and governments will avoid throwing large amounts of
money in networks that are strongly influenced by private entities. Litereum's
simplicity makes it viable for companies, and even individuals, to implement
their own full nodes, without trusting anyone else's code. This transparency
makes Litereum politically decentralized and, thus, a less risky choice for big
players looking to migrate their assets from fiduciary to cryptographic money.
### How is that possible?
Below are some of the major differences that make this possible:
#### 1. No native account system
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
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,
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
more secure, algorithm, like Lamport or WOTS. They can even set up multiple
signature options for the same account. Nothing is hard-coded.
#### 2. No native currencies, only functions
Ethereum has a native currency, Ether, that is used to pay miner fees. Litereum
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",
"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,
the following snippet:
@Katarina({
call miner = get_miner_identity()
call Dog.send(42, miner)
call Lit.send(42, miner)
call Lit.send(1000, @Ahri)
done
}, "c803cb81...cb92880c") // signature here
Is a block of code signed by an user called @Katarina. Once mined, that snippet
would run in behalf of Katarina, paying 42 DOG and 42 LIT tokens as fees for the
block miner, and sending 1000 LIT tokens to @Ahri. In effect, this has the exact
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, previsible. Since
there isn't a native currency, there isn't 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
their individual profits.
#### 3. A simpler block structure
Ethereum block structure is complex due to both historical artifacts that are
often regarded as mistakes (such as logs), and to optimizations that, while
clever, are not used in practice and sometimes even obsolete (such as
patricia-merkle trees).
![ethereum_block_header.png](Ethereum block structure)
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
run full nodes, or trust someone that does.
#### 4. A simple concensus algorithm
Ethereum aims to migrate to a complex Proof-of-Stake consensus algorithm. While
that choice will bring several benefits such as lower energy consumption and
faster finality times, it also makes the protocol, as a whole, considerably more
complex. Even Ethereum's current implementation of Proof-of-Work is complex due
to the adoption of Ethash and the GHOST.
Litereum's consensus algorithm is just Proof-of-Work, exactly as used on
Bitcoin, except slightly simpler since there are no native fees. Proof-of-Work
is straightforward to implement and, in fact, only a small fraction of
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.
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.
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.
Design
------
Litereum's design is split in two parts:
### 1. LitCore
The execution environment where users create and interact with tokens, contracts
and applications. It has a built-in scripting language based on the affine,
simply-typed, lambda calculus. Recursive functions, algebraic datatypes,
pattern-matching and 64-bit unsigned integers are the only computational
primitives. Stateful computation is possible because programs are allowed to
mutably rebind global definitions. Communication is possible because programs
can call each-other. That is, a message is just an external function call, and
the reply is just the returned value.
### 2. LitCons
The consensus algorithm. Nodes connect in a peer-to-peer network to create and
exchange blocks of pure data. LitCons is completely separate from LitCore,
<TODO>
Implementation
--------------
Litereum's design is a combination of 3 components:
### 1. LitCore
1. LitCons: a minimal, proof of work consensus algorithm.
2. LitSign: a minimal, quantum-resistant, hash-based signature scheme.
3. LitCore: a minimal, statically typed affine calculus used for scripting.
### LitCore
LitCore is a affine, simply typed, functional language featuring recurive
functions, algebraic datatypes, pattern-matching and a global state, called
world. It can be seen as the virtual machine running inside Litereum. Every type
and algorithm required to implement LitCore will be specified below.
Types:
#### Bits
@ -239,99 +387,7 @@ A case in a pattern-match. It has 2 fields:
- `body : Term`: the term returned by that case
LitSign
-------
LitCons uses a configuration of WOTS for message authentication, based on the
Keccak256 function. To be able to sign messages, an user must first generate a
random 256-bit word as its seed. From this seed, the user can generate private
keys by concatenating and hashing `keccak(seed | n | i)` for each natural number
`i` up to `32` (exclusive), where `n` is the number of the private key. That is:
```
function private_key(seed, n):
private_key = []
for i from 0 to 32:
private_key.push(keccak(seed | n | i))
return private_key
```
A public key can then be generated by taking `keccak^256(w)`, for each word `w`
in the private key, concatenating these results, and taking its hash. That is:
```
function public_key(private_key):
public_key = []
for i from 0 to 32:
hash = private_key[i]
for j from 0 to 256:
hash = keccak(hash)
public_key.push(hash)
return keccak(public_key)
```
The user must then broadcast his public key as his public identifier, and keep
his private key secret. To sign a message `M` the user must first generate a
256-bit summary of `M`. That summary consists of the last 30 bytes of the
Keccak of the message, prefixed with the sum of these bytes. That is:
```
function summary(message):
hash = keccak(message)[2..32] # last 30 bytes of the hash
byte_0 = sum(hash) / 256 # first byte of the checksum
byte_1 = sum(hash) % 256 # second byte of the checksum
summary = byte_0 | byte_1 | hash # the 32-byte summary
return summary
```
Then, for each natural number `i`, up to `32`, the signer must take
`256 - summary[i]` consecutive hashes of `private_key[i]`. The concatenation of
these 32 hashes is the 1024-bytes signature. That is:
```
function sign(private_key, summary):
signature = []
for i from 0 to 32:
value = private_key[i]
for i from 0 to 256 - summary[i]:
value = keccak(value)
signature.push(value)
return signature
```
A public key can be recovered from a signature and a summary by, for each
natural number `i`, up to `32`, taking `summary[i]` consecutive hashes of
`signature[i]`. That is:
```
function recover(summary, signature):
public_key = []
for i from 0 to 32:
hash = signature[i]
for i from 0 to summary[i]:
hash = keccak(hash)
public_key.push(hash)
return keccak(public_key)
```
To check if a signature is valid, the verifier must check if the public key
returned by `recover()` matches with the one published. That is:
```
function valid(message, signature, public_key):
return recover(summary(message), signature) == public_key
```
This signature scheme has 120 bits of classical security, and 80 bits of
post-quantum security. It has a signature size of 1024 bytes, and requires an
average of 4096 hashes per signature and verification. This is an one-time
signature scheme, which means that, once a message is signed with a public key,
that public key must be thrown away, and a new one must be generated. In
Litereum, every time an user makes a transaction, they broadcasts the new
public key to the network.
LitCons
-------
### 2. LitCons
LitCons is a data-only blockchain. It could be described as "Bitcoin without the
coin". It is the consensus layer used by Litereum to order blocks (pages) in its