💎

Bitcoin, Ethereum

데이터구조

genesis block 최초의 블록

비트코인 첫 블록은 타임즈 신문으로 중앙화된 경제구조의 문제를 보여주는 내용.

genesis block 이후의 블록들은 이전 블록의 해시 데이터를 가지고 있다.

DAG (Directed Acyclic Graph)

방향이 있는 비순환 그래프.

어떤 트랜잭션이 먼저 처리되었는지 구분할 수 있는 메커니즘을 만들어야 함.

트랜잭션은 confirm되려면 다른 transaction에 의해서 refernce되어야한다.

fence를 쳐서 앞에있는 모든 트랜젝션은 먼저 처리되게 하는 global synchronization point가 있다

t3와 t4사이에는 순서가 없다.

t5는 레퍼런스되지 않은 잊혀진 트랜잭션으로 fence쳐서 t5먼저 처리하고 t6, t7이 실행됨

UTXO

UTXO = unspent transaction output 아직 쓰지않은 잔액.

비트코인 네트워크에서는 잔액이라는 개념이 존재하지 않음. 트랜젝션에 의한 결과물들의 합을 잔액이라는 개념으로 사용한다. 이것이 UTXO이다. 각 지갑의 UTXO는 해당 지갑 주인에 대해 공개키 암호로 잠겨있다. 즉 private key로 암호화되어있다. 내 잔고가 얼마라는 정보는 없다. 내가 갖고 있는 UTXO의 합이 잔고가 된다.

모든 비트코인 transaction은 미래에 다른 transaction의 input이 될 수 있는 output을 생성한다. UTXO는 아직 사용되지 않은 transaction output. 비트코인을 트랜잭션들의 그래프라고 한다면 UTXO는 끝단을 말함.

트랜잭션이 발생하면 기존 UTXO를 소비하고 새로운 UTXO를 생성한다.

1BTC와 3BTC를 받았다면 4비트코인이 아니라 1비트와 3비트를 각각 UTXO로 저장하고 금액을 송금할때는 기존 UTXO를 파기한다. 4비트코인 UTXO에서 2비트만 전송한다면 2비트는 채굴자에게 간다.

특정 계좌의 잔고를 알기가 어렵지만 해당 기능을 제공하고 있음

UTXO기반 블록체인은 프로그래밍 가능성이 약하다.

account-based model

이더리움에서 사용하는 구조.

계정 방식에서 상태는 블록으로 전송되지 않고 로컬로 노드에 저장됨. 노드는 Merkle Root를 비교해서 상태에 대한 합의에 도달함. 계정기반모델은 UTXO와 다르게 코인을 분할하거나 합쳐서 트랜잭션을 발생시킬 수 있다.

계정 방식에서는 잔고를 파악하기 쉽지만 history를 파악하기 어렵다.

Programming Model

비트코인도 bitcoin script 스크립트를 내장하고 있지만 programmabilty가 높진 않음

비트코인은 디지털 금이다. 기능이 없다.

이더리움에서 사용하는 smart contract langauge는 Solidity, Vyper

EVM

EVM은 바이트코드를 쓴다. Solidity compiler가 Yul을 뱉고 Yul컴파일러가 EVM Bytecode로 전환한다.

Bitcoin Core

RPC를 통한 앱과 HTTP 통신
RPC(원격 프로시저 호출)는 애플리케이션과 서버 간의 통신을 가능하게 하는 프로토콜입니다. HTTP를 통해 RPC를 구현하면, 애플리케이션이 서버에 직접 요청을 보내고 응답을 받을 수 있습니다. 이를 통해 블록체인 노드와 상호작용하고 트랜잭션을 생성하거나 블록 정보를 조회하는 등의 작업을 수행할 수 있습니다.

내장 지갑
내장 지갑은 블록체인 애플리케이션 내에서 개인 키와 공개 키를 생성하고 관리하는 기능을 제공합니다. 사용자는 자신의 지갑을 통해 암호화폐를 송금하고 수신할 수 있으며, 지갑의 안전성을 위해 다양한 보안 기능(예: 비밀번호, 생체 인식 등)을 사용할 수 있습니다.

Peer Discovery
Peer discovery는 블록체인 네트워크에서 다른 노드(피어)를 발견하는 과정입니다. 이를 통해 노드는 상호 연결되고, 네트워크의 안전성과 분산성을 유지할 수 있습니다. 일반적으로 부트노드(bootnode)는 초기 연결을 위한 노드로, 다른 노드의 IP 주소를 알고 있으며, 새로운 노드가 네트워크에 참여할 때 필요한 정보를 제공합니다.

부트노드
부트노드는 네트워크의 초기 연결 지점을 제공합니다. 새로운 노드가 블록체인 네트워크에 참여할 때, 부트노드를 통해 다른 노드들의 IP 주소를 얻고, 네트워크에 연결됩니다. 부트노드는 안정성을 위해 신뢰할 수 있는 노드로 설정되는 경우가 많습니다.

최신 블록 유지
노드는 필요한 최신 블록만 메모리에 유지하여, 불필요한 데이터를 방지하고 성능을 최적화합니다. 이는 블록체인 동기화 과정에서 중요한 요소로, 효율적인 데이터 관리가 가능합니다.

Mempool (메모리 풀)
Mempool(메모리 풀)은 아직 블록에 포함되지 않은 대기 중인 트랜잭션의 집합입니다. 이 풀에 있는 트랜잭션들은 네트워크에서 전파되고, 해당 트랜잭션이 블록에 포함되기 위해 대기합니다. Mempool은 노드가 유효한 트랜잭션을 관리하고, 수수료에 따라 우선순위를 조정하는 데 도움을 줍니다.

PKI (Public Key Infrastructure)
PKI는 공개 키 기반 구조로, 공개 키와 개인 키를 안전하게 관리하고 배포하는 시스템입니다. PKI를 통해 인증서 발급, 키 관리 및 데이터 암호화가 가능해지며, 블록체인에서는 거래의 서명을 위한 키 쌍을 생성하는 데 필요합니다.

공개 키 및 개인 키
개인 키: 비밀리에 보관해야 하는 키로, 소유자가 암호화폐를 송금할 수 있는 권한을 부여합니다.
공개 키: 개인 키에서 연산되어 생성된 키로, 다른 사용자에게 공개할 수 있습니다. 공개 키는 거래의 서명을 검증하는 데 사용됩니다.

주소 생성 과정
공개 키는 직접 주소로 사용되지 않고, 다음과 같은 해싱 과정을 거칩니다:
공개 키: 64바이트의 길이를 가집니다.
SHA-256 해싱: 공개 키를 SHA-256 해싱하면 32바이트의 해시 값이 생성됩니다.
RIPEMD-160 해싱: SHA-256 해시를 RIPEMD-160 해싱하면 20바이트의 해시 값이 생성됩니다. 이 값이 비트코인 주소의 기본이 됩니다.
이 과정을 통해 생성된 주소는 사용자가 다른 사람에게 암호화폐를 수신하기 위해 사용할 수 있는 형식으로 변환됩니다.

Merkle Tree

머클 트리는 이진 트리의 일종으로 트리의 루트를 머클 루트라고 한다.

두개씩 거래를 묶은다음 sha256으로 해싱하고, 묶은 값들을 다시 두개씩 묶어서 해싱하며 Merkle root하나만 남을때까지 계속한다. 그럼 수백개의 거래값들을 하나의 데이터로 만들어주는것과 같다.

머클 트리를 사용하면 특정 거래를 찾는 경로가 단순해진다. 해싱된 횟수만큼 경로를 찾아가는 연산을 하면 특정 거래 데이터를 쉽게 찾을 수 있다. 블록체인의 용량은 지속적으로 증가하기 때문에 모든 블록체인을 다운받는 풀 노드는 적다. 따라서 머클 트리를 사용하면 블록 데이터의 일부만 다운받는 라이트 노드를 구현할 수 있다.

Block Data Structure

블록은 트랜잭션의 껍데기라고 할 수 있다.

hash	Hash value of the block
confirmations	block height difference between the latest block header and this block header
height	The number of blocks from the genesis block. Genesis block height is 0.
merkleroot	The root of the merkle tree of the block’s transactions. Detail
time	The time when the block was generated
tx	The list of transactions in the block
previousblockhash	block hash of the previous block
nonce	A random value to obtain a block hash satisfying block difficulty

GetBlockCount

curl -X POST https://bitcoin-mainnet.public.blastapi.io \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"1.0","id":0,"method":"getblockcount"}'
Shell
복사

genesis block으로부터 지금까지의 height을 받아온다.

GetBlockHash

가장 최근의 블럭의 해시를 얻어오려면 block count를 알아야하고

block의 컨텐츠를 얻으려면 block의 해시를 구해야한다.

curl -X POST https://bitcoin-mainnet.public.blastapi.io\
 -H 'Content-Type: application/json'\
 -d '{"jsonrpc":"1.0","id":0,"method":"getblockhash","params":[866858]}'
Shell
복사

Getblock

얻어온 block hash를 parameter로 block의 정보를 받아온다

curl -X POST https://bitcoin-mainnet.public.blastapi.io \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"1.0","id":0,"method":"getblock","params":
["00000000000000000000d53d298ac1fcd3bf88cb89010e6d41181eb55e826a88"]}'
Shell
복사

GetRawTransaction

curl -X POST https://bitcoin-mainnet.public.blastapi.io \
-H 'Content-Type: application/json' 
-d '{"jsonrpc":"1.0","id":0,"method":"getrawtransaction","params":["f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",true]}'
Shell
복사

{
  "result": {
    "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",
    "hash": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",
    "version": 1,
    "size": 275,
    "vsize": 275,
    "weight": 1100,
    "locktime": 0,
    "vin": [
      {
        "txid": "0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9",
        "vout": 0,
        "scriptSig": {
          "asm": "304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09[ALL]",
          "hex": "47304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901"
        },
        "sequence": 4294967295
      }
    ],
    "vout": [
      {
        "value": 10,
        "n": 0,
        "scriptPubKey": {
          "asm": "04ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84c OP_CHECKSIG",
          "desc": "pk(04ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84c)#hsw9ejus",
          "hex": "4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac",
          "type": "pubkey"
        }
      },
      {
        "value": 40,
        "n": 1,
        "scriptPubKey": {
          "asm": "0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 OP_CHECKSIG",
          "desc": "pk(0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3)#u7qfa49l",
          "hex": "410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac",
          "type": "pubkey"
        }
      }
    ],
    "hex": "0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000",
    "blockhash": "00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee",
    "confirmations": 866691,
    "time": 1231731025,
    "blocktime": 1231731025
  },
  "error": null,
  "id": 0
}
Shell
복사

Transaction Data structure

txid	Transaction ID
hash	Transaction Hash (differs from txid for witness transactions)
version	version of the transaction
size	serialized transaction size
vsize	virtual transaction size (differs from size for witness transactions)
weight	Transaction’s weight. A block can hold up to 4M weight units.
locktime	Delay the transaction to be mined. if locktime < 500M, the value means height. Otherwise, it means unixtime.
vin	UTXOs used for this transaction
blockhash	the blockhash where this transaction is in
vout	UTXOs created by this transaction

Fee Calculation

vin에서 vout으로 나간 양의 합을 빼면 Fee가 나온다

Segwit

세그윗(SegWit, Segregated Witness)은 비트코인 블록체인에서 거래 데이터의 구조를 개선하기 위해 도입된 기술로, 주로 디지털 서명을 거래의 입력에서 분리하여 효율성을 높이는 방식입니다.

서명의 분리: 세그윗은 거래의 서명을 입력에서 분리하여 별도의 데이터 구조인 '증인(witness)'으로 이동시킵니다. 이렇게 함으로써 거래의 크기를 줄이고, 블록에 더 많은 거래를 포함할 수 있게 됩니다.

UTXO(사용되지 않은 거래 출력): 비트코인 거래는 입력과 출력으로 나뉘며, 입력은 소유자가 소비 가능한 UTXO와 해당 UTXO에 대한 서명 및 공개키로 구성됩니다. 세그윗은 이 과정에서 서명을 분리하여 입력의 크기를 줄이는 데 도움을 줍니다.

TXID와 TXHASH: 세그윗의 도입으로 인해 거래의 ID(TXID)와 해시(TXHASH)가 다를 수 있습니다. 이는 세그윗 거래가 서명을 분리함으로써 발생하는 현상으로, 블록체인에서 거래를 참조할 때 이러한 차이를 이해해야 합니다.

증인은 암호쪽에서는 암호 해독을 말하는 것이고, 여기서는 디지털 서명을 말한다. (비트코인에서 서명은 서명 + 소유자 공개키로 구성된다.)

세그윗은 원리적으로는 세그윗이라는 이름과 같이 서명을 거래의 입력에서 분리하여 다른 곳으로 옮겨놓는 기술이다.

비트코인에서 거래는 입력과 출력으로 구성된다. 입력은 소유자가 소비가 가능한 출력, 즉 UTXO를 말하고, 이것은 자신의 UTXO와 서명과 공개키로 이루어졌고, 출력은 받는 사람의 주소와 보내는 코인량으로 이루어졌다.

아래는 거래의 raw 포맷을 보여준다.

기존 방법 : [nVersion][txins][txouts][nLockTime] ----------- (1) 시그윗 : [nVersion][marker][flag][txins][txouts][witness][nLockTime] ----- (2)

여기서 nVersion: 버전, txins: 입력, txouts:출력, nLockTime: 잠금시간(블럭에 기록될 수 있는 시간)이다.

세그윗은 [txins]에 포함되었던 서명을 [witness]로 옮겨놓은 것이다. 즉, 크게 보면 서명의 위치를 [txins]에서 [witness]로 이동시킨 것으로서, 이것은 거래 구조를 변경한 것이다.

이 한가지를 한 것이 아니라, 거래의 출력 형태도 바꾸어서 출력의 사이즈를 조금 줄였다. 이로서, UTXO의 사이즈가 조금 줄어드는 효과가 있어서, 램에 상주하는 UTXO의 크기를 조금은 줄여준다.

세그윗의 효과는 1) 거래의 사이즈를 최대 75% 정도 절약할 수 있다. 즉, 서명이 차지하던 부분은 새로운 항목인 [witness]로 옮겨놓아서 기존 구조에서 인식하는 사이즈로 보면, 서명 부분만큼 새로운 거래 데이터가 더 블럭에 포함될 수 있게 된 것이다.

Taproot

Taproot 탭루트(Taproot)는 비트코인 프로토콜의 중요한 업그레이드로, 거래의 프라이버시와 효율성을 크게 향상시키기 위해 설계되었습니다. 주로 슈노 시그니처(Schnorr Signatures)와 결합되어 여러 서명을 효율적으로 처리하는 데 기여합니다.

슈노 시그니처(Schnorr Signatures) 단일 서명으로 다중 서명 검증: 슈노 시그니처는 여러 서명을 하나의 서명으로 결합할 수 있는 특성을 가지고 있습니다. 이를 통해 여러 사용자가 참여하는 멀티시그(Multisig) 거래의 서명을 단일 서명처럼 처리할 수 있어, 거래 데이터의 크기를 줄이고 검증 과정을 간소화합니다.

효율성 및 보안: 슈노 시그니처는 기존 ECDSA(타원 곡선 디지털 서명 알고리즘)보다 더 효율적이며, 보안성 또한 높습니다. 이는 거래를 보다 안전하고 빠르게 처리할 수 있도록 도와줍니다.

비트코인의 거래 처리 속도 TPS(Transactions Per Second): 비트코인은 평균적으로 7-10 TPS(초당 거래 수)를 처리할 수 있습니다. 이는 비트코인의 확장성 문제를 나타내며, 많은 거래가 동시에 발생할 경우 블록 생성에 지연이 발생할 수 있습니다.

블록 생성 지연: 블록체인 네트워크에서 한 시간 동안 블록을 생성하지 못하는 경우도 발생할 수 있습니다. 이는 네트워크의 혼잡도나 기타 기술적 문제로 인해 발생할 수 있으며, 사용자에게 불편을 초래할 수 있습니다.

멀티시그(Multisig) 서명 요구: 멀티시그 거래는 두 개 이상의 서명이 필요합니다. 이는 보안성을 높이는 데 기여하지만, 거래 처리 시 여러 서명이 필요하므로 시간이 더 걸릴 수 있습니다. 결제 채널(Payment Channel) 거래 관련성: 결제 채널은 사용자 간의 거래를 오프체인에서 처리할 수 있게 해 주는 기술입니다. 이는 블록체인에 거래를 등록할 필요 없이 여러 거래를 수행할 수 있게 하여, 블록체인 네트워크의 혼잡을 줄이는 데 기여합니다.

효율적 거래 처리: 결제 채널을 사용할 경우, 모든 거래를 블록체인에 기록할 필요가 없으며, 최종 결과만 블록체인에 기록합니다. 이로 인해 거래 비용이 줄어들고, 처리 속도가 빨라질 수 있습니다.

1. 라이트닝 네트워크 (Lightning Network)

라이트닝 네트워크는 비트코인 블록체인의 확장성 문제를 해결하기 위한 2차 솔루션입니다. 이 기술은 비트코인 트랜잭션의 속도와 비용을 개선하기 위해 설계되었습니다.

•

작동 원리: 라이트닝 네트워크는 두 사용자 간에 비트코인 트랜잭션을 즉시 처리할 수 있는 오프체인 결제 경로를 생성합니다. 사용자는 '지불 채널'을 열고, 이 채널을 통해 다수의 트랜잭션을 수행할 수 있습니다. 채널을 닫을 때 최종 상태만 블록체인에 기록됩니다.
두 사용자 간의 반복적인 transaction처리에 좋다. 하지만 N-to-N 커뮤니케이션은 너무 무거워진다.
직접 payment channel을 각각 여는것이 아니라 중간에 존재하는 사람들을 거쳐서 전송함

•

장점:

◦

속도: 트랜잭션이 즉시 처리되므로 빠른 결제가 가능합니다.

◦

비용 절감: 오프체인에서 트랜잭션을 처리하므로 수수료가 낮아집니다.

◦

확장성: 수천만 개의 트랜잭션을 처리할 수 있는 잠재력을 가지고 있습니다.

•

단점:

◦

채널 관리: 사용자는 지불 채널을 관리해야 하며, 이는 복잡할 수 있습니다.

◦

유동성 문제: 채널에 자금이 부족할 경우 트랜잭션이 실패할 수 있습니다.

2. 스택스 (Stacks)

스택스는 비트코인 블록체인 위에 스마트 계약과 분산 애플리케이션을 구축할 수 있는 플랫폼입니다. 스택스는 비트코인의 보안성을 활용하면서도 더 복잡한 기능을 제공합니다.

•

작동 원리: 스택스는 비트코인과 연결되어 있으며, 이더리움과 유사한 스마트 계약 기능을 제공합니다. 개발자는 Clarity라는 프로그래밍 언어를 사용하여 스마트 계약을 작성합니다.

•

장점:

◦

비트코인 보안: 비트코인의 보안과 안정성을 그대로 활용합니다.

◦

스마트 계약: 다양한 분산 애플리케이션을 개발할 수 있는 기능을 제공합니다.

◦

자산 소유: 비트코인 기반의 자산 및 디지털 토큰을 생성하고 거래할 수 있습니다.

•

단점:

◦

복잡성: 비트코인과의 통합 및 스마트 계약 개발이 복잡할 수 있습니다.

◦

사용자 인식 부족: 많은 사용자들이 스택스의 개념을 잘 이해하지 못할 수 있습니다.

3. 루트스톡 (Rootstock)

루트스톡은 비트코인과 호환되는 스마트 계약 플랫폼으로, 비트코인 블록체인에 직접 연결되어 있습니다. 이더리움의 기능을 비트코인으로 가져오는 것이 주요 목표입니다.

•

작동 원리: 루트스톡은 비트코인 블록체인에 연결된 사이드체인으로 작동하며, 이더리움과 유사한 방식으로 스마트 계약을 실행합니다. 비트코인을 루트스톡으로 잠금(locked)하여 루트스톡의 토큰인 RSK를 생성할 수 있습니다.

•

장점:

◦

비트코인과의 호환성: 비트코인의 보안과 신뢰성을 활용합니다.

◦

스마트 계약 기능: 이더리움과 유사한 스마트 계약을 지원합니다.

◦

확장성: 다양한 디앱(DApp)을 쉽게 구축할 수 있습니다.

•

단점:

◦

복잡한 구조: 사이드체인과의 상호작용이 복잡할 수 있습니다.

◦

상대적으로 낮은 채택률: 비트코인 생태계 내에서의 인지도가 상대적으로 낮을 수 있습니다.

BRC-20

BRC-20은 비트코인 블록체인에서 새로운 토큰 표준을 나타내며, 주로 비트코인 생태계에서 디지털 자산이나 토큰을 생성하고 관리하기 위한 규칙을 제공합니다. 이 표준은 이더리움의 ERC-20과 유사하지만, 비트코인 네트워크의 특성을 반영하여 설계되었습니다. 토큰 생성 및 관리: BRC-20은 사용자가 비트코인 블록체인에서 쉽게 토큰을 생성하고 거래할 수 있도록 합니다. 이를 통해 다양한 디지털 자산을 만들고, 이를 다른 사용자와 교환할 수 있습니다.

스마트 계약: BRC-20은 비트코인 네트워크에서 스마트 계약 기능을 지원합니다. 스마트 계약은 미리 정의된 조건이 충족되면 자동으로 실행되는 계약으로, BRC-20을 통해 더 복잡한 금융 거래를 가능하게 합니다.

비트코인과의 호환성: BRC-20은 비트코인 네트워크의 특성에 맞춰 설계되었기 때문에, 비트코인과의 호환성이 높습니다. 이를 통해 기존 비트코인 사용자들이 쉽게 접근할 수 있습니다.

BRC-20의 활용 사례 디지털 자산 거래: BRC-20을 사용하여 다양한 디지털 자산을 생성하고 거래할 수 있습니다. 예를 들어, NFT(대체 불가능한 토큰)와 같은 자산을 만들 수 있습니다.

탈중앙화 금융(DeFi): BRC-20을 통해 사용자들은 다양한 금융 서비스를 이용할 수 있습니다. 예를 들어, 대출, 스테이킹, 유동성 제공 등이 가능합니다.

커뮤니티 및 프로젝트 지원: BRC-20을 활용하여 커뮤니티 기반 프로젝트에 자금을 모으거나, 특정 목적을 위한 토큰을 생성하여 사용자들의 참여를 유도할 수 있습니다.

오디널스 프로토콜

•

오디널스 프로토콜은 비트코인의 최소 단위인 사토시에 데이터를 첨부해서 일종의 NFT를 만들 수 있게 구현한 기술이다.

•

1 비트코인은 1억개의 사토시로 이뤄져 있다. 여기서 각각의 사토시에는 순서대로 번호가 자동으로 매겨지는데, 이때 매겨지는 번호를 오디널스(Ordinals)라고 한다.

•

소프트웨어 프로그래머인 케이시 로더머(Casey Rodarmor)가 이 특성을 이용해서 2023년 1월 오디널스 프로토콜을 만들었다.

•

첨부할 수 있는 데이터는 이미지, 텍스트, 프로그램, 비디오 등이다. 이론적으로는 최대 블록 당 4MB의 데이터를 비트코인 블록체인에 새겨넣을 수 있다.

•

오디널스 프로토콜과 비슷한 아이디어는 비트코인 비교적 초창기였던 2014년에도 있었다. 그러나 당시에는 블록에 최대 80바이트(byte)의 데이터 밖에 담을 수 없었다. 기존 비트코인에 2017년 세그윗 업그레이드와 2021년 탭루트 업그레이드가 추가되면서 이런 시도가 가능하게 됐다.

•

현존하는 BRC-20 토큰은 대부분 오디널스 프로토콜을 이용해 유통된다. 

BRC-20

•

BRC-20은 오디널스 프로토콜을 이용해 비트코인 블록체인에 대체 가능토큰(FT)을 형성할 수 있는 일종의 표준 이름이다.

•

BRC-20이라는 이름은 이더리움 블록체인의 가장 대중적인 토큰 표준인 ‘ERC-20’에서 따온 것으로 보인다. 사실 ERC-20과는 공통점보다 차이점이 더 많다.

•

이름은 비슷하지만 ERC-20과는 기능에서 큰 차이가 있다. 가장 큰 차이는 이더리움 스마트컨트랙트의 자동 계약 기능이 없다는 것이다.

•

BRC-20은 원시적인 형태의 P2P토큰 전송 정도가 가능한 상태다. 토큰을 팔려는 사람이 가격을 적어서 올려두면 각각 1:1로 거래하는 식이다.

Ethereum

클라이언트가 2가지로 구성 consensus client execution client

메인넷 = 분산형 디지털 네트워크. 메인넷의 노드는 개별 컴퓨터 또는 서버

메인넷은 사용자 트랜잭션을 확인 처리 검증 기록하는 대가로 금전적 보상을 받는 네트워크 노드의 참여로 운영됨

이더리움 거래 유형

이더리움 거래 유형은 다양한 거래 방식과 수수료 구조를 지원하기 위해 발전해왔습니다. 다음은 각 거래 유형에 대한 설명입니다.

Type 0: Legacy Transaction
설명: 전통적인 이더리움 거래 방식으로, 이더리움 네트워크의 초기 버전에서 사용되었습니다.
수수료 구조: 거래 수수료는 가스 가격(gas price)과 가스 한도(gas limit)에 따라 계산됩니다. 사용자가 설정한 가스 가격에 따라 수수료가 결정되며, 높은 가스 가격을 설정하면 거래가 더 빠르게 처리될 수 있습니다.
특징: 이 거래 유형은 단순하며, 복잡한 기능이나 추가적인 수수료 최적화를 제공하지 않습니다.

Type 1: Access List Transaction
설명: EIP-2930에 의해 도입된 거래 유형으로, 특정 스마트 계약과 주소에 대한 접근 목록(access list)을 포함합니다.
수수료 구조: 이 거래는 접근 목록에 포함된 주소에 대해 추가적인 수수료를 줄이는 방식으로 작동합니다. 이로 인해 가스 비용을 예측할 수 있고, 높은 수수료가 발생하는 상황을 줄일 수 있습니다.
특징: 이 거래 유형은 특히 복잡한 스마트 계약을 호출할 때 유용하며, 거래 처리 속도를 개선하고 가스 비용을 효율적으로 관리할 수 있도록 도와줍니다.

Type 2: EIP-1559 Transaction
설명: EIP-1559에 의해 도입된 거래 유형으로, 새로운 수수료 모델을 기반으로 합니다. 이 모델은 기본 수수료(base fee)와 추가 수수료(tip)로 구성되어 있습니다.
수수료 구조: 기본 수수료는 블록의 혼잡도에 따라 동적으로 조정되며, 사용자는 이 기본 수수료에 추가하여 자신이 원하는 수수료를 설정할 수 있습니다. 이는 거래의 우선순위를 높이는 데 도움을 줍니다.
특징: EIP-1559 거래는 더 예측 가능한 수수료 구조를 제공하며, 기본 수수료는 블록에 포함될 때 소각되어 공급량을 줄이는 효과를 가져옵니다. 이는 이더리움의 경제 모델에 긍정적인 영향을 미칠 수 있습니다.

Merkle Tree

머클트리는 여러 데이터에 단계적으로 해시함수를 적용하여 결국에 하나의 해시값으로 나타내는 데이터 구조다.

쉽게 말해서, 여러 개의 데이터를 하나의 해시값으로 만드는 데이터 구조다. 해시트리랑 같은 의미로 쓰인다.

이렇게 여러 데이터를 모아 만들어진 하나의 최종 해시값을 "Merkle Root"라고 한다.

맨위를 보면 블록전체의 데이터를 하나의 헤시값으로 나타내고 있고 Header부분에는 이전 블록의 해시값, 버전, 난이도, 트랜잭션 데이터 머클루트, 블록생성시간, 논스 등에 대한 데이터가 들어간다.

Header부분에 들어가는 Merkle Root가 위에서 설명한 머클트리로 만들어진 해시값이다.

결국 블록의 모든 transaction이 블록 Header에 들어가고 이 Header의 정보들이 최종적으로 Block Hash값으로 나타나게되니 이전 블록의 transaction정보가 변경되면 모든 블록의 hash값이 변화하게 될 것이다.(쇄도효과라고 한다, avalanche effect).

머클트리는블록체인의 무결성을 보장한다.

맨 아래의 원본 데이터가 변경되면 순차적으로 위의 해시값이 바뀌게 되며 결국 맨 위에 존재하는 머클 루트 해시값도 바뀔 것이기 때문이다.

이러한 원리를 통해서 우리는 Merkle Root 해시값만 보더라도 트리 아래의 트랜잭션 데이터가 변경되었는지, 손상되었는지 간편하게 파악할 수 있다.

이더리움은 이더리움 네트워크 전체를 나타내는 머클트리가 따로 존재한다. 이러한 방식으로 작성된 머클트리의 데이터는 블록체인 네트워크 전체를 보았을 때 데이터의 저장용량이 훨씬 가벼워 진다. 이더리움은 이러한 방식을 적용해서 변화가 일어나지 않는 노드들은 건들지 않고 상태변화가 일어나는 노드들만 업데이트 해준다. 때문에 비트코인의 전체 블록데이터는 100GB가 넘는 반면 이더리움은 10GB정도 된다고 한다.\

Patricia Tree

패트리샤 트리(Patricia Tree)는 데이터 구조의 일종으로, 주로 키-값 저장소에서 사용됩니다. 이 구조는 일반적인 트리 구조의 변형으로, 특히 문자열이나 바이너리 데이터의 검색과 저장에 매우 효율적입니다. 패트리샤 트리는 "Practical Algorithm to Retrieve Information Coded in Alphanumeric"의 약자입니다.

패트리샤 트리는 일반적인 트리와 달리 공통된 접두사를 공유하는 노드를 합쳐서 표현합니다. 이렇게 함으로써 트리의 깊이를 줄이고, 메모리 사용량을 효율적으로 관리합니다.

각 노드는 키의 비트 또는 문자에 따라 분기되며, 이를 통해 검색과 삽입 작업이 빠르게 수행됩니다. 예를 들어, 문자열의 길이가 서로 다를 때 공통된 부분을 공유하여 트리를 압축합니다.

키를 기반으로 한 검색이 매우 빠르며, 평균적으로 O(k) 시간 복잡도를 가집니다. 여기서 k는 키의 길이입니다. 이는 대량의 데이터에서 특정 키를 빠르게 찾는 데 유리합니다.

패트리샤 트리는 해시값을 포함할 수 있어 데이터의 무결성을 검증하는 데 유용합니다. 이더리움의 패트리샤 머클 트리와 유사하게, 데이터가 변경되면 해시값이 변경되므로 데이터의 불변성을 유지할 수 있습니다. 사용 사례: 패트리샤 트리는 이더리움 블록체인뿐만 아니라, 다양한 응용 프로그램에서 키-값 저장소, 라우팅 테이블, 자동 완성 기능 등 여러 용도로 사용됩니다.

Gas Fee 측정

이더리움은 스마트 컨트랙에서 얼마나 많은 연산을 하냐에 따라서 Gas Fee를 지불함

Epoch and Slot

이더리움의 epoch와 slot은 이더리움 2.0(이더리움의 지분 증명(PoS) 기반 업그레이드)에서 블록 생성 및 검증 프로세스를 관리하는 구조입니다.

Epoch (에포크) 에포크는 일련의 슬롯으로 구성된 시간 단위입니다. 이더리움 2.0에서 epoch은 32개의 슬롯으로 이루어져 있으며, 각 에포크는 약 6분 정도의 시간을 소요합니다.

에포크는 블록체인 상태를 업데이트하고, 검증자를 관리한다. 예를 들어, 에포크가 끝날 때마다 검증자들은 자신의 상태(예: 보상 등)를 평가받습니다. 에포크의 끝에서는 블록체인의 상태가 정리되고, 검증자들의 활동이 집계됩니다.

Slot (슬롯) 슬롯은 블록 생성의 가장 작은 단위입니다. 이더리움 2.0에서는 각 슬롯이 약 12초 정도의 시간을 소요합니다. 각 슬롯에서 새로운 블록이 생성될 수 있습니다. 슬롯은 블록 생성 및 검증의 주기를 정의합니다. 각 슬롯에서 특정 검증자가 블록 생성 권한을 부여받고, 해당 검증자는 새로운 블록을 작성하여 네트워크에 추가할 수 있습니다.

각 슬롯에서 블록을 생성할 검증자는 무작위로 선택되어 보안성을 높이고, 모든 검증자가 공평하게 블록 생성 기회를 가질 수 있도록 합니다.

Blockchain Trilemma

블록체인 트릴레마(Blockchain Trilemma)는 블록체인 기술에서 세 가지 주요 특성인 보안(Security), 탈중앙화(Decentralization), 확장성(Scalability)을 동시에 만족시키기 어렵다는 개념입니다. 이 세 가지 특성은 블록체인 시스템의 성능과 신뢰성에 중요한 요소로 작용합니다. 보안 (Security): 블록체인의 데이터는 무결성을 유지해야 하며, 외부 공격이나 부정 행위를 방지해야 합니다. 보안이 강화되면 네트워크의 신뢰성이 높아지고, 사용자들이 안심하고 거래할 수 있습니다.

탈중앙화 (Decentralization): 블록체인은 특정 중앙 기관이나 단일 주체에 의존하지 않고, 여러 참여자가 네트워크를 운영하는 구조입니다. 탈중앙화는 시스템의 투명성과 신뢰성을 높이는 데 기여하지만, 이를 유지하려면 네트워크의 참여자 수가 많아야 합니다.

확장성 (Scalability): 블록체인이 많은 거래를 처리할 수 있는 능력을 의미합니다. 확장성이 높아지면 더 많은 사용자와 거래를 지원할 수 있지만, 이 과정에서 보안이나 탈중앙화가 희생될 수 있습니다.

확장성을 높이기 위해 거래 속도를 증가시키면 보안이 약화될 수 있습니다. 반대로 보안을 강화하면 거래 처리 속도가 느려질 수 있습니다. 다양한 블록체인 프로젝트들은 이 트릴레마를 해결하기 위해 여러 접근 방식을 시도하고 있습니다.

예를 들어, 레이어 2 솔루션(예: 라이트닝 네트워크)은 거래 속도를 높이면서도 기본 블록체인의 보안성을 유지하려고 합니다. 또한, 일부 프로젝트는 새로운 합의 알고리즘을 도입하여 보안과 확장성을 동시에 개선하려고 합니다.

Rollup

롤업은 이더리움의 확장성 솔루션으로, 이더리움의 레이어 1과 레이어 2를 조화롭게 활용하여 효율적인 거래 처리와 사용자 경험을 개선하는 데 중점을 둔 접근 방식입니다.

Layer 1 (이더리움) 데이터 가용성 레이어 (Data Availability Layer),보안 레이어 (Security Layer)

레이어 1은 블록체인 데이터의 가용성을 보장합니다. 모든 거래와 상태 변화를 기록하고, 이를 네트워크 참여자들이 접근할 수 있도록 합니다. 데이터 가용성이 확보되어야 레이어 2의 거래 결과를 안전하게 확인할 수 있습니다.

이더리움의 레이어 1은 네트워크의 보안을 담당합니다. 합의 메커니즘에 의해 모든 거래가 검증되고, 이를 통해 사용자 자산과 거래의 안전성을 보장합니다. 레이어 2는 레이어 1의 보안성을 활용하여 거래의 신뢰성을 높입니다. Layer 2 (롤업) 더 빠른 확인,더 낮은 거래 비용

레이어 2 솔루션, 특히 롤업은 거래를 오프체인에서 처리하여 블록 생성 시간을 단축시킵니다. 이렇게 하면 사용자들은 더 빠르게 거래 결과를 확인할 수 있습니다.

레이어 2에서는 거래를 한꺼번에 묶어 처리할 수 있어 가스 비용이 절감됩니다. 이는 사용자들이 더 저렴한 수수료로 거래를 수행할 수 있도록 합니다.

레이어 2 솔루션은 특정 애플리케이션이나 서비스에 맞게 설계될 수 있습니다. 개발자들은 자신들의 필요에 맞게 최적화된 환경에서 스마트 계약을 배포하고, 사용자 경험을 개선할 수 있습니다.

롤업(Rollup)은 두 가지 주요 유형이 있습니다: Optimistic Rollup과 Zero-Knowledge Rollup(ZK Rollup). 각 유형의 특징은 다음과 같습니다.

Optimistic Rollup
옵티미스틱 롤업은 블록이 유효하게 생성되었다고 가정하는 방식입니다. 즉, 모든 거래가 정상적으로 처리되었다고 믿고 진행합니다.

블록이 생성된 후, 블록의 유효성을 검증할 수 있는 기간이 주어집니다. 이 기간 동안 사용자나 검증자는 거래의 유효성을 확인할 수 있습니다. 최소한 하나의 정직한 검증자가 존재하는 경우, 유효하지 않은 블록을 발견할 수 있습니다. 만약 블록이 잘못 생성되었다면 이를 신고하여 검증할 수 있습니다.

구현이 상대적으로 간단하고, 거래 처리 속도가 빠릅니다.

잘못된 거래가 발생할 경우, 이를 검증하는 데 시간이 걸리며, 악의적인 사용자가 존재할 경우 보안에 취약할 수 있습니다.

Zero-Knowledge Rollup
제로-지식 롤업은 거래의 유효성을 "제로 지식 증명"을 통해 증명하는 방식입니다. 즉, 거래가 유효하다는 것을 증명할 수 있지만, 거래의 내용을 공개하지 않습니다.

블록의 유효성을 검증하기 위해 노드가 거래를 직접 확인할 필요가 없습니다. 대신, 유효성을 증명하는 증명서를 생성하여 제출합니다. 이 증명서는 거래의 유효성을 보장하며, 이를 통해 블록체인 상태를 업데이트할 수 있습니다.

거래의 프라이버시를 보장하며, 블록의 유효성을 빠르게 검증할 수 있습니다. 블록체인에 저장되는 데이터의 크기를 줄일 수 있어, 전체적인 효율성을 높입니다.

증명서를 생성하는 과정이 계산적으로 매우 무겁기 때문에, 초기 설정 및 처리 비용이 높을 수 있습니다.

Zero-Knowledge Proof

아무정보도 주지 않고 내가 정보를 가지고 있다고 증명하는 방법

The Alibaba cave

prover, verifier

prover는 비밀번호를 알고 verifier는 모른다.

비밀번호를 verifier에게 에게 노출하지 않으면서 어떻게 안다는것을 증명할수있을까?

prover가 b로 들어갔을때 verifier가 a로 나오라고 하는상황에서 비밀번호를 알야아만 통과할 수 있다

문만열면 되고 verifier에게 비밀번호를 보여줄필요는 없다.

NP문제는 증명하려면 prover가 굉장히 많은 일을 해야하고 verifier는 polynomial time에 검증할 수 있다. PoW에서 해시를 만드는 사람은 어려운데 주어진 해시를 verifier가 검증하는 것은 쉬운것과 같다.

prover가 n=pq인 p와 q를 보내고 n=pq인지 검증자는 검증한다.

y=x**2 mod N인 x가 있다

y를 알고있을때 수식에 해당하는 x를 prover가 알고있으면 값을 주면 된다

verifier는 y만아는 상태에서 x를 알아내기 어렵지만 prover가 x를 보내주면 성립하는지 확인.

isomorphic점만 움직여서 같은 모양을 만드는 문제는 모든 관계를 다 확인해봐야하는 복잡한 문제라서 시간이 오래 걸린다. prover가 claim에 대해서 어떤 변형이 일어났는지 증명값을 던져주면 verifier가 검증할 수 있다

핵심은 값을 모르면 증명하기 어려운 문제를 prover가 답을 던져줘서 풀수있도록 한다.

verifier가 색맹일 때 어떻게 두가지 색깔로 이루어진 종이라는것을 검증할수있을까?

verifier가 동전을 던지고 앞이 나오면 뒤집고 뒤가 나오면 그대로 둔다. 그 결과를 prover에게 주고 뒤집혔는지 묻는다. 답이 내것과 동일하다면 두개의 페이지로 이루어져있는걸 알수있다.

prover가 p,q값을 줘야한다

두 경로를 선택하라고 하고 한 경로는 naive한 경로고 한쪽은 어려운 경로

둘중에 하나만 줄테니까 뭘 받을지 골라라

b가 0일때와 b가1일때

b = 0일때 z²=sy mod N이 되고

original x에 뭔가 곱한값을 주기 때문

이차합동식 x2≡a(mod p)이 해를 가지면, a를 p의 이차 잉여류(quadratic residue)라 한다.

x를 숨기면서 검증한다 랜덤값을 섞어서 보내면 된다

b=1일때는 x에 대한 정보를 알려주지 않고

b=0일때는 b를 고른다는 얘기는 x값에는 관심이 없는것 a를 고른다는건 x값을 알아야한다

b=0이든1이든 관계없이 증명할수있음

b=1은 검증이 나쁜사람이어도 되고 b=0은 검증이 안됨

그래도 accept할 확률이 1/2는 되는건데

100번 수행하면 나쁜 사람이 통과할 가능성은 굉장히 낮을것.

해시도 충돌하는게 있긴 하지만 굉장히 확률이 낮은것처럼 100퍼센트는 없지만 거의 불가능하다.

honest verifier인 경우 완벽한 zero knowlege