mirror of
https://github.com/autistic-symposium/blockchains-security-toolkit.git
synced 2025-05-13 04:02:16 -04:00
💾
This commit is contained in:
parent
982078a66c
commit
98e5bd2cce
8 changed files with 0 additions and 0 deletions
10
basic_knowledge/cryptography/README.md
Normal file
10
basic_knowledge/cryptography/README.md
Normal file
|
@ -0,0 +1,10 @@
|
|||
## cryptography
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
|
||||
* [keccak](keccak.md)
|
||||
* [asymmetric cryptography](asymmetric_crypto.md)
|
9
basic_knowledge/cryptography/asymmetric_crypto.md
Normal file
9
basic_knowledge/cryptography/asymmetric_crypto.md
Normal file
|
@ -0,0 +1,9 @@
|
|||
## 🍈 asymmetric crypto
|
||||
|
||||
<br>
|
||||
|
||||
* a private key in etherem is 64 random hex characters (or 32 bytes or 256 bits)
|
||||
* the public key is derived from the private key using elliptic curve digital signature algorith (ECDSA)
|
||||
* the ethereum address are the first 20 bytes of the SHA3 hashed public key
|
||||
* the private key creates a signature, the public key verifies the signature
|
||||
* when you transfer ether from one address to another, the tx is signed by your private key
|
52
basic_knowledge/cryptography/keccak.md
Normal file
52
basic_knowledge/cryptography/keccak.md
Normal file
|
@ -0,0 +1,52 @@
|
|||
## 🥐 keccak
|
||||
|
||||
<br>
|
||||
|
||||
### hashing
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
* hashing is a mathematical op converting an input message into a digest
|
||||
* the transformation of a str of characters into a (usually shorter) fixed-length value or key that represents the original string.
|
||||
* used to determine the integrity of a message, fast data retrieval and to encrypt/decrypt digital signatures
|
||||
* collisions found: MD5 (128, 1992), SHA-1 (160, 1995)
|
||||
* no collisions found: SHA-2 (224/256/384/512, 2001)
|
||||
|
||||
<br>
|
||||
|
||||
### secure hash algorithm (SHA)
|
||||
|
||||
<br>
|
||||
|
||||
* family of cryptographic hash functions by NIST
|
||||
* preprocessing: padding the data for blocking (fixed size message blocks)
|
||||
|
||||
<br>
|
||||
|
||||
### SHA-3/keccak
|
||||
|
||||
<br>
|
||||
|
||||
* 2012 as the winner of the NIST hash function competition
|
||||
* based on the sponge function: variable input and output length
|
||||
* parameters (decides the strength):
|
||||
* r bits: rate, defines speed
|
||||
* c bits: capacity, defines the security level
|
||||
* no key schedule, instead round constants
|
||||
* state us 5x5x64 bits block
|
||||
* the rho module rotates each 64-bit element by a triangular number: 0, 1, 3, 6, 10, 15...
|
||||
* the pi module permutes the 64-bit elements
|
||||
* the chi module adds a non-linear aspect to the permutation round
|
||||
* the iota module breaks up any symmetry caused by the other modules, through XORing one of the array elements to a round constant
|
||||
|
||||
<br>
|
||||
|
||||
##### application & strength
|
||||
|
||||
<br>
|
||||
|
||||
* high level of parallelism
|
||||
* flexibility, bit interleaving
|
||||
* suited for protection against side-channel attack
|
||||
|
12
basic_knowledge/decentralized_storage/README.md
Normal file
12
basic_knowledge/decentralized_storage/README.md
Normal file
|
@ -0,0 +1,12 @@
|
|||
## decentralized storage
|
||||
|
||||
### tl; dr
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
### resources
|
||||
|
||||
|
||||
* [forgotten IPFS vulns](https://consensys.net/diligence/blog/2022/09/the-forgotten-ipfs-vulnerabilities)
|
36
basic_knowledge/evm_and_opcodes/README.md
Normal file
36
basic_knowledge/evm_and_opcodes/README.md
Normal file
|
@ -0,0 +1,36 @@
|
|||
## the evm
|
||||
|
||||
|
||||
### tl;dr
|
||||
|
||||
* EVM is a quasi-Turing complete machine (quasi because computation is intrinsically bounded/limited through a parameter: gas)
|
||||
* EVM is the runtime environment for smart contracts.
|
||||
* "Ethereum virtual machine code" or "EVM code" are cute lil code are written in a low-level, stack-based bytecode language, each byte represents an operation.
|
||||
* EVM memory is a simple stack-based architecture with: stack, volatile memory, non-volatile storage (word size of 256-bit) and the fearful Calldata.
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### in this repo
|
||||
|
||||
<br>
|
||||
|
||||
* [my favorite opcodes](evm_and_opcodes/my_favorite_opcodes.md)
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
|
||||
<br>
|
||||
|
||||
* [opcodes for the evm](https://ethereum.org/en/developers/docs/evm/opcodes/)
|
||||
* [opcodes and instruction reference](https://github.com/crytic/evm-opcodes)
|
||||
* [EVM Contract Construction](https://blog.smlxl.io/evm-contract-construction-93c98cc4ca96)
|
||||
* [ethersplay](https://github.com/crytic/ethersplay)
|
||||
* [IDA EVM](https://github.com/crytic/ida-evm)
|
||||
* [Ethereum book](https://github.com/ethereumbook/ethereumbook)
|
||||
* [Ethereum's Whitepaper](https://ethereum.org/en/whitepaper/)
|
||||
* [Understanding rollups](https://barnabe.substack.com/p/understanding-rollup-economics-from?s=r)
|
21
basic_knowledge/evm_and_opcodes/my_favorite_opcodes.md
Normal file
21
basic_knowledge/evm_and_opcodes/my_favorite_opcodes.md
Normal file
|
@ -0,0 +1,21 @@
|
|||
## 🐼 my favorite opcodes
|
||||
|
||||
<br>
|
||||
|
||||
| opocde | name | min gas | details |
|
||||
| ----------- | ----------- | ----------- | --------------- |
|
||||
| 20 | SAH3 | 30 | keccak-256 hash of the given data in memory |
|
||||
| 31 | BALANCE | 100 | balance of a given 20-byte address in wei |
|
||||
| 33 | CALLER | 33 | the 20-byte address of the last caller account (except delegate call) |
|
||||
| 3A | GASPRICE | 2 | gas price in wei per gas |
|
||||
| 40 | BLOCKHASH | 20 | hash of the chosen block, or 0 if the block is not the valid range |
|
||||
| ~☠️44🪦~ | DIFFICULT | 😵 | current block difficulty |
|
||||
| 45 | GASLIIT | 2 | get gas limit |
|
||||
| 48 | BASEFEE | 2 | get base fee in wei |
|
||||
| 5A | GAS | 2 | remaining gas after instructions |
|
||||
| F0 | CREATE2 | 32000 | create a new contract - the new account's code is set to the return data resulting from executing the inialisation code - the destination address is calculated as `initialisation_code = memory[offset:offset+size]` and `address = keccak256(0xff + sender_address + salt + keccak256(initialisation_code))[12:]` |
|
||||
| F1 | CALL | 100 | create a new sub context and execute the code of the given account, then resumes the current one |
|
||||
| F2 | CALLCODE | 100 | create a new sub context and execute the code of the given account - the storage remains the same |
|
||||
| F4 | ✨DELEGATECALL✨ | 100 | create a new sub context and execute the code of the given account - the storage, the current sender, and the current value remain the same |
|
||||
| FA | STATICCALL | 100 | create a new sub context and execute the code of the given account, then resumes the current one - equivalent to CALL, except that it does not allow any state modifying instructions or sending ETH in the sub context |
|
||||
| FF | SELFDESTRUCT | 5000 | the new account is registered to be destroyed at the end of the current transaction |
|
66
basic_knowledge/l2_and_rollups/README.md
Normal file
66
basic_knowledge/l2_and_rollups/README.md
Normal file
|
@ -0,0 +1,66 @@
|
|||
## l2s && rollups
|
||||
|
||||
### tl; dr
|
||||
|
||||
* the current Ethereum version has low transaction throughput and high latency in processing. This means that transactions are both slow and prohibitively expensive, due to high demand, relative to what the network can take at any given time.
|
||||
* there are two types of scaling solutions:
|
||||
|
||||
- On-chain scaling refers to any direct modification made to a blockchain, like data sharding and execution sharding in the incoming Ethereum 2.0.
|
||||
- Off-chain scaling refers to any innovation outside of a blockchain, i.e., the execution of transaction bytecode happens externally instead of on Ethereum. hese solutions are called L2, because layer 2 works above layer 1 (Ethereum) to optimize and speed up processing. Arbitrum and Optimism Ethereum are two well-known examples of L2 scaling solutions.
|
||||
* there are two leading L2 solutions:
|
||||
- Zero-Knowledge (zk) rollups, and
|
||||
- Optimistic rollups
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
#### zk-rollups
|
||||
|
||||
* zk-rollups bundle together many off-chain transactions into a single verifiable batch using zk-SNARK.
|
||||
* zk-SNARK is an extremely efficient, zero-knowledge proof that allows one party to prove it possesses certain information without revealing that information. These validity proofs are then posted to the Ethereum blockchain.
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
#### optimistic rollups
|
||||
|
||||
* Instead of executing and storing all the data on Ethereum, where transactions are only processed at a premium, we only store a summary.
|
||||
* All the actual computation and storage of contracts and data is done on L2.
|
||||
* Rollups inherit Ethereum's security guarantess, while still acting as an efficient scalin solution.
|
||||
* Optimistic rollup batch together off-chain transactions into braches, without a proof of their validity.
|
||||
* When assertions of the L2 state are posted on-chain, validators of the rollup can challenge the assetion when they think there is a malicious state (fraud detection).
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
#### state channel
|
||||
|
||||
* setting up channels between parties to form an off-chain network within which many transactions take place
|
||||
* final state is updated on ethereum
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
#### side cain
|
||||
|
||||
* conduct txs in a separate blockchain with its own consensus mechanism
|
||||
* assets and data are transferred with ethereum through a smart contract that locks assets and recreates representative opens in the side chain
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
#### plasma chain
|
||||
|
||||
* similar to side chains, functioning as separate chains with their own consensus mechanisms
|
||||
* roots of each block are published to ethereum, which makes the system more secure but limits its ability for complex operations
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
---
|
||||
|
||||
### resources
|
8
basic_knowledge/l2_and_rollups/circom.md
Normal file
8
basic_knowledge/l2_and_rollups/circom.md
Normal file
|
@ -0,0 +1,8 @@
|
|||
## [circom](https://docs.circom.io/)
|
||||
|
||||
<br>
|
||||
|
||||
* circom is a domain-specific language (dsl) and a compiler that can used to generate and verify zkps.
|
||||
* zkps are powerful cryptographic tools that allow you to make proofs about a statement witout reveling any private information
|
||||
* circom and other dls are used to describe a computation, together with a set of constraints on the program in/output
|
||||
* the circom compiler takes a program and generates a prover and a verifier
|
Loading…
Add table
Add a link
Reference in a new issue