컨센서스
컨센서스는 말 그대로 '합의'를 말한다.
비트코인에서 컨센서스라고 하면, 비트코인을 채굴하는 채굴자들 사이에 공통적으로 합의하고 있는 내용을 말한다.
특히 비트코인에서 중요한 합의는 Canonical Block Chain에 대한 합의가 중요하다.
각각의 노드마다 생각하는 Canonical Block Chain이 다르다면, 누구는 어떤 블록이 유효하다고 하고, 누구는 유효하지 않다고 말할 것이기 때문이다.
또한 블록체인은 일종의 은행장부와 같다.
어떤 노드는 이 블록체인에 따르면 A가 100만원을 갖고 있다고 해서 A가 100만원을 송금하려고 하는데, 어떤 노드는 A가 50만원 밖에 갖고 있지 않다고 여겨서 거부하면 A입장에서는 난 100만원을 갖고 있는데 왜 50만원으로 인식이 되는지 이해할 수 없을 것이다.
기존의 전통적인 중앙화된 시스템에서는 서버에 모든 내용이 기록되었을 것이기에 이런 문제가 없었겠지만,
비트코인은 각각의 노드가 분산된 블록 체인 데이터를 갖고 있다보니 이 데이터가 일치하는 것이 매우 중요해졌다.
분산 시스템의 특성상, 어떤 특정 시점에 딱 봤을 때 모든 full node가 정확히 동일한 블록체인의 형태를 보고 있지 않을 수는 있다.
하지만 그 조금 이전의 과거 시점으로 가면 그 시점까지는 모두가 일치했을 것이고, 지금은 조금씩 다르더라도 나중에는 결국 하나의 canonical chain으로 수렴하여 의견이 모아질 것이기 때문에 괜찮다.
정리하면, 비트코인은 어떤 중앙의 권위 기관이 존재하지 않으며, 모든 full node가 동일한 공공 장부의 전체 데이터 복사본을 갖고 있어 이 기록을 권위적인 데이터로서 믿을 수 있다.
그리고 이를 위해서는 어떤 특정 노드의 힘이 있는 것이 아니라 모든 노드가 동등한 힘을 갖고 있기 때문에 여러 노드들이 생각하는 '정확한 장부' 에 대한 의견 합의를 이끌어 내는 것이 중요하다.
각각의 시점에서 각 full node가 생각하는 '정확한 장부'는 독립적으로 생각하기 때문에 일시적으로 다를 수 있기 때문이다.
비트코인의 블록 생성 기준 시간이 10분으로 설정된 이유도, 이 의견 합의를 이끌어내는데 편하기 때문이다.
매 트랜잭션마다 합의를 보는 것은 힘드니까, 트랜잭션을 묶은 블록으로 합의를 보고, 이때 블록은 10분마다 생성되니까 10분마다 그때까지의 트랜잭션들을 가지고 합의를 보는 것이다.
비트코인의 합의 절차는 다음과 같다.
1. 모든 full node 는 모든 트랜잭션을 독립적으로 검증한다.
몯든 노드는 이웃 노드에게 트랜잭션을 포워딩하기 전에 이 트랜잭션이 유효한지 검증한다.
유효하지 않은 트랜잭션을 포워딩해도 어차피 블록에 포함되지 않으므로 뿌리는 것이 의미가 없기 때문이다.
만약 검증 결과가 유효하지 않다면, 이 트랜잭션을 최초로 받은 full node는 이 트랜잭션을 버린다.
검증의 대상은 다음과 같다.
- 트랜잭션의 문법과 데이터 구조가 올바른지
- 트랜잭션의 스크립트가 올바른지 (비트코인의 경우, 스크립트에 반복문을 쓴다면 유효한 스크립트가 아니다)
- 트랜잭션의 utxo가 사용되지 않은 utxo 인지
- 트랜잭션의 스크립트가 유효한지
- 트랜잭션의 크기가 최대 허용 크기보다 작은지 (witness data를 제외했을 대 블록에 들어갈 수 있는 크기인지)
2. 모든 mining node 는 각자 독립적으로 검증한 트랜잭션을 묶어서 블록으로 만들고, 채굴을 시도한다.
(채굴 = 블록 해시 값이 특정 값보다 작아지는 nounce 값 찾기 = 작업 증명)
과거 비트코인 초창기에는 nonce 필드에 넣을 수 있는 값을 모두 시도해보면 해시 퍼즐을 충분히 풀 수 있었지만, 난이도가 점점 증가하면서 32bit nonce 필드에 넣을 수 있는 40억 가지의 값을 모두 시도해도 해시퍼즐을 풀 수 없게 되었다.
그래서 이때는 코인베이스 트랜잭션의 input 필드를 nonce 값을 담는 공간으로 활용하여 트랜잭션 해시를 계산한다.
이 공간에는 2~100바이트 사이의 랜덤한 값을 넣을 수 있다. (0 바이트로 아무것도 안 담는 것은 x)
따라서 이 공간과 기존의 nonce 필드를 모두 활용하면 매우 많은 가짓수의 nonce값을 시도할 수 있다.
3. 채굴된 블록은 다른 노드들에 의해 추가로 검증되며, 검증에 성공하면 체인에 포함된다.
(검증 = 트랜잭션은 모두 유효한지, 해시 퍼즐은 맞게 풀었는지, 현재 채굴 난이도 기준에 맞게 풀었는지 체크)
4. 모든 노드는 독립적으로 이후에 어떤 블록 뒤에 추가적으로 이어서 채굴할 지 결정하며, 그 중에서 먼저 작업 증명에 의해 앞서 나가는 체인을 canonical chain 으로 여긴다.
예시
최초에 위 그림과 같이 별표 모양의 블록이 canonical block 으로 모두 생각하고 있는 상태에서 시작해보자.
이때 멀리 떨어진 두 노드가 서로 다른 블록을 채굴해서 별 모양 블록에 붙였다고 해보자.
해당 노드는 자신이 채굴한 블록이 인정받기를 원하므로, 신속하게 인접한 노드에게 뿌린다.
그러다가 결국 모든 노드는 연결되어있기 때문에 정삼각형을 인정하는 노드와 역삼각형을 인정하는 노드 모두 역삼각형과 정삼각형 블록이 새로 채굴되어 별 모양 블록에 붙고자 하는 것을 확인한다.
이때 정삼각형을 인정하는 노드들은 이미 정삼각형을 받아들인채 그 뒤에 이어붙일 블록을 채굴하고 있었을 것이므로, 역삼각형 블록은 받아들이지 않는다.
마찬가지로 역삼각형을 인정하는 노드들은 역삼각형을 뒤에 이어붙일 블록을 채굴하고 있었을 것이므로 정삼각형 블록을 인정하지 않는다.
그러다가 정삼각형을 인정해서 채굴하고 있던 노드가 다이아몬드 모양 블록을 채굴했다고 해보자.
그러면 그 블록을 신속하게 주변에 뿌릴 것이다.
이때 이 정보를 만약 역삼각형을 인정하는 노드가 수신했다면, 그 노드는 기존에 인정했떤 역삼각형 블록을 버리고 정삼각형 블록과 함께 다이아몬드 모양 블록을 받아들인다.
그러면 최종적으로 위와 같이 다이아몬드 블록을 인정하는 형태로 컨센서스가 이루어진다.
Consensus Attack
비트코인은 충분히 컨센서스에 대해 공격을 받을 수 있다.
만약 특정 비트코인 채굴자들이 많은 돈을 들여서 채굴장비를 준비한 뒤, 막대한 해시 파워를 이용해서 비트코인을 뒤흔들고자 한다면 충분히 흔들릴 수 있다.
그리고 실제로도 그런 공격을 시도하는 사람들이 있었다. 이 사람들은 비트코인의 약점을 찾아서, 이를 이용해 돈을 벌고자 했다.
하지만 적어도 대규모 조직이 그런 공격을 시도한 경우는 없었고, 이런 사람들은 소수였기 때문에 시스템 자체를 흔들 수는 없었다.
그래서 비트코인을 정말 흔들고 싶다면 단순히 비트코인이 망하는 것을 보고 싶어서 정말 엄청난 돈을 쏟아부을 수 있는 사이코가 존재해야 한다. 현실적으로는 마이너 풀들이 연합해서 시스템을 흔들고자 한다면 충분히 흔들 수 있다.
그래서 이를 막기 위해서 비트코인은 비트코인의 가치를 계속 올린다.
그러면 비트코인을 통해 돈을 버는데 관심있는 사람들은 굳이 돈을 들여서 시스템을 흔들 생각을 하지 않는다.
이처럼 비트코인의 컨센서스가 워낙 단단해서 컨센서스를 공격하는 사람들은 다른 사람의 돈을 뺏으려고 하지 않는다.
돈을 뺏으려면 canonical block을 뒤집을정도로 강력한 해시 파워를 사용해서 이전 블록으로부터 현재 높이의 블록까지 뻗어와야 하는데 현실적으로 쉽지 않기 때문이다.
그래서 대부분의 공격은 도스 (Denial of Service) 공격에 머문다.
(즉, 비트코인에 대한 공격은 현재 블록과 가까운 미래의 컨센서스에만 영향을 줄 수 있다.)
예를 들면 앨리스가 밥에게 특정 비트코인을 보냈고, 이 트랜잭션이 컨펌되었다고 해보자.
그런데 공격자가 이 트랜잭션이 마음에 들지 않으면, 이 트랜잭션을 제외한 블록을 포크해서 이 블록을 제일 긴 체인으로 만들어버릴 수는 있다.
이런 방법으로 골탕을 먹일 수는 있지만, 앨리스의 돈을 탈취한다거나 할 수는 없다.
(이것도 6개 컨펌 정도까지가 가능성이 있고, 그 이상을 넘어가면 현실적으로 역전시키기는 쉽지 않다.)
또한 컨센서스 공격은 서명 알고리즘과 private key 와 관련된 보안에는 영향을 줄 수 없다.
이 보안은 워낙 수학적으로 안전하다고 여겨져있고, 실제로도 깨진적이 없다.
(거래소의 보안 취약점을 이용해서 비트코인을 탈취한 사례는 존재하긴 한다.)
그래서 비트코인에는 51% 공격이라는 것이 있다.
51%는 과반 이상을 나타내는 상징적인 숫자로, 만약 공격자가 51% 이상의 해시파워를 가지면 이론적으로 비트코인의 시스템을 흔들 수 있게 된다. (비트코인이 절대로 안전한 것은 아니지만, 적어도 다른 시스템보다 취약하지는 않다. 어떤 시스템도 그 시스템에 영향을 줄 수 있는 과반 이상이 공격하면 버틸 수 있는 시스템이 없기 때문이다.)
이때 double-spend 는 공격자 자신의 트랜잭션에 대해서만 할 수 있다.
(정확히는 공격자 자신이 가져올 수 있는 utxo에서 비트코인을 꺼내오는 트랜잭션에 대해서만 할 수 있다.)
왜냐하면 서명 자체가 유효하지 않으면 블록이 받아들여지지 않기 때문에, 내가 한번 지불한 뒤, 같은 output을 다른 곳에 한번 더 지불하려면 나의 서명이 꼭 필요하기 때문이다.
(아무리 해시 파워를 많이 장악해도 서명을 위조할 수 없기 때문에 다른 사람의 코인을 뺐을 수는 없다.)
double-spend 공격은 트랜잭션이 컨펌되기 전에 시도할 수 있다.
내가 a인데 b에게 보내는 트랜잭션을 뿌리고, 그 트랜잭션이 블록에 포함되기 전에 다시 나에게 보내는 트랜잭션을 뿌리고자 할 수 있다.
만약 이미 a에서 b로 보내는 트랜잭션이 한번 컨펌되었다면, 그 컨펌을 뒤집기 위해서 많은 해시파워를 사용해야 한다.
그렇다면 만약 내가 a인데 b에게 값을 지불하고 물건이나 서비스를 받은 상태에서 double spend를 시도하면, b입장에서는 최소한 1 confirmation 이후에 물건이나 서비스를 내고자 할 것이므로, 이때는 confirmation 이후에 공격을 시도해야 한다.
또는 어떤 특정 비트코인에서 활동하는 사람에게 불이익을 주기 위해서 해시 파워를 사용해 그 사람이 발생시키거나 그 사람에게 들어가는 모든 트랜잭션을 포함하지 않도록 막을 수 있다. (도스 공격)
실제로 비트코인의 안전성에 대한 연구가 진행되기도 했다.
그런데 보안을 연구하는 그룹에서 발표한 내용에 따르면 비트코인 시스템을 흔들 때는 30%정도의 해시파워만 장악해도 충분히 시스템을 흔들 수 있다고 한다.
다행히 아직까지는 30% 해시파워를 갖는 싱글 그룹도 없었고, 있었다고 해도 공격을 한 적은 없다.
(공격하기보다 그 파워로 채굴한 비트코인의 가치를 지키는 것이 이득이기 때문이다.)
그런데 만약 30% 파워를 갖는 그룹이 공격을 시도했고, 이것이 어느정도 유효한 것으로 보인다면, 기존의 비트코인에 참여하는 노드 중 일부는 공격자의 편에 서는 것이 이득이라고 생각해서 그 그룹의 크기가 점점 커질 가능성은 있다.
다행히 아직 실제로 그런 일이 발생한 적은 없다.
컨센서스 규칙의 변화
비트코인 네트워크와 소프트웨어는 계속해서 발전하고 있다.
대표적인 예시가 세그윗이다.
세그윗은 블록 사이즈를 증가시키는 것을 목적으로 등장했지만, 트랜잭션의 순환 참조 문제와 같은 문제도 함께 해결했다.
따라서 지금처럼 비트코인에 많은 이해관계를 생긴 상황에서는 비트코인에 대한 위협이 발생했을 때 이를 적극적으로 조치하고자 할 것이다.
컨센서스 규칙은 결국 어떤 트랜잭션과 어떤 블록이 유효하다고 받아들일지를 결정하는 규칙이다.
이 규칙은 초기 사토시 나카모토가 정한 규칙에서 크게 달라지지 않았다.
Proof of Work 도 그대로고, sha256 알고리즘을 사용해서 타겟 넘버보다 작은 해시값을 찾아야 하는 것도 그대로이다.
물론 규칙이 절대로 바뀌지 않는다고는 할 수 없다.
만약 해시 파워가 너무 좋아서 3~4분이면 해시 퍼즐을 풀 수 있는데 10분까지 기다렸다 퍼뜨리는 것에 불만이 있어서 기준 시간을 8~7분 정도로 줄이고자 한다면 합의를 통해서 충분히 줄일 수는 있을 것이다.
(물론 프로그램 버그 같은 것은 비트코인 코어에서 빠르게 고쳐서 퍼뜨리긴 한다.)
Hard Fork
비트코인의 규칙을 바꿀 때는 하드 포크와 소프트 포크로 구분할 수 있다.
하드 포크는 말 그대로 두 갈라진 포크가 서로 융합하지 못하고 완전히 갈라지는 것을 말한다.
그 둘 사이의 합의 규칙이 아예 달라져서 기존의 규칙대로 생성한 트랜잭션을 새로 포크된 프로젝트에서는 유효하지 않다고 받아들이는 것이다. 그래서 하드포크는 거의 선택을 하지 않고, 웬만하면 소프트포크로 해결하려고 한다.
하드포크는 완전히 새로운, 서로 다른 규칙에 의해 블록체인 시스템이 돌아가야 할 때 발생한다.
그게 버그가 될 수도 있다. 버그를 회피해서 가자고 할 수도 있고, 아니면 그냥 고치고 새롭게 시작하자고 할 수도 있다.
하드포크의 대표젹 예시는 블록 크기의 제한에 대한 의견이 갈려서 떨어져나온 비트코인 캐시가 있다.
비트코인 캐시는 아무 제한 없이 블록의 크기 상한을 8MB로 늘렸다.
따라서 비트코인 캐시의 블록은 비트코인에서 유효한 블록으로 보지 않는다.
하드포크가 발생하면 이 규칙에 맞게 업그레이드 하지 않은 노드는 새로운 컨센서스 규칙에 참여할 수 없고, 기존의 체인에 남아있을 수 밖에 없다. (not forward compatible)
블록 높이 7부터는 ECDSA 기반이 아닌 새로운 해시 알고리즘을 사용하자고 합의가 이루어졌다고 해보자.
a는 기존의 규칙만 따르는 노드가 채굴한 블록, b는 신규 합의를 따르는 노드가 채굴한 블록이다.
그러면 이 시점 이후부터는 새로운 규칙을 따르는 노드들이 열심히 채굴해서 블록을 이어붙일 것이다.
(7 이전에는 4b와 같이 새로운 규칙을 적용해도 유효하지 않다고 본다.)
그런데 이를 거부하는 노드들이 기존 방식대로 채굴해서 주황색 블록을 생성했다고 해보자.
이 노드들은 7b 와 같은 형식의 블록을 유효하지 않다고 판단해서 이들의 트랜잭션과 블록을 거부할 것이다.
그런데 만약 b를 채굴하는 블록들이 기존의 서명 방식과 새로운 서명 방식을 모두 받아들이겠다고 하면, 그때는 8b에서 새로 추가된 서명 방식의 트랜잭션을 포함하지 않았더라도, 신규 규칙을 따르는 노드들이 이 노드를 유효한 블록으로 보고 그 뒤에 이어서 채굴할 것이다.
물론 주황색 노드들은 그럼에도 불구하고 8b를 인정하지 않을 것이다.
왜냐하면 8b가 참조하는 이전 블록이 자신들이 인정하지 않는 블록이므로 고아 블록으로 여기기 때문이다.
결론적으로 하드포크는 커뮤니티에서 굉장히 부담스러워한다.
하드 포크를 하게 되면 의견에 반대하는 소수의 그룹 사람들이 강제로 떠나도록 만들기 때문이다.
그래서 절대 다수가 찬성하는 경우가 아니면 하드포크는 잘 일어나지 않는다.
비트코인에서는 2015년에 세그윗이 제안되었고, 2017년에 구현되어 적용되었다.
이때 세그윗은 절대 다수가 찬성했기에 하드포크로 갔어도 별 문제가 없었을 것 같지만, 실제로는 소프트 포크로 적용해서 세그윗을 따르지 않는 노드도 세그윗을 따르는 노드의 트랜잭션을 받아들일 수 있도록 했다.
(세그윗을 따르는 노드는 세그윗을 따르지 않는 노드의 트랜잭션을 받아들이지 않는다.)
Soft Fork
만약 변경점을 구현할 때 non-upgraded client 도 기존의 방식을 계속 사용할 수 있도록 구현하면 이를 소프트 포크라고 부른다.
(사실 소프트 포크는 '포크'가 아니긴 하다. 포크는 완전히 갈라진다는 의미를 내포하기 때문이다.)
하지만 업그레이드를 하지 않은 클라이언트는 불이익이 있다.
업그레이드를 한 클라이언트는 업그레이드를 하지 않은 클라이언트를 인정하지 않으므로 업그레이드를 하지 않은 클라이언트의 입지가 줄어들고, 이들의 트랜잭션이 받아들여지기가 힘들어지기 때문이다.
그래서 궁극적으로는 업그레이드를 하지 않은 클라이언트는 업그레이드를 할 수 밖에 없게 된다.
소프트포크는 기존의 룰에 제약 사항을 추가하는 방식으로만 진행된다.
이를 통해 forward compatible 하게 규칙을 변경할 수 있으며, 기존 규칙을 따르는 노드도 새로운 규칙의 형태를 여전히 받아들일 수 있다. 하지만 그 반대는 받아들이지 않는다.
비트코인에는 세그윗 말고도 여러 소프트 포크가 존재했다.
소프트 포크를 진행하는 방법 중에 nop 라는 OP 코드를 사용하는 방법이 있다.
비트코인은 nop 라는 OP 코드에 1부터 10까지 값을 지정을 해두고, 나중에 필요하면 1번은 어떤 목적으로, 2번은 어떤 목적으로 쓰도록 10개의 op코드를 만들어둔 것이다.
그래서 이를 이용하면 뭔가 업그레이드 시킨 것을 상대방에게 알려줄 수 있다.
예를 들어 1번에 무슨 값을 넣으면 그것은 특정 업그레이드를 적용한다는 뜻이라고 약속한다.
그러면 기존 노드는 nop1 을 받으면 그냥 아무것도 없는 값으로 인식하지만, 이 규칙을 따르는 노드는 nop1을 그 규칙을 적용한 동작으로 해석할 것이다.
소프트 포크에 대해서는 여러가지 비판이 제기되기도 한다.
먼저 포크 이전의 사용자와 포크 이후의 사용자를 모두 지원하려면 코드가 복잡해질 수 밖에 없고 버그가 발생할 위험도 증가한다.
이를 가리켜 기술적 부채가 생긴다고 표현한다.
또한 포크 이전의 노드는 포크 이후의 블록에 대해 유효하다고 판단한다.
이때 포크 이후의 기준에서는 유효하지 않음에도 포크 이전의 노드는 유효하다고 판단할 수 있으므로 유효성 검사의 효과가 감소한다.
포크 이전의 노드는 포크 이후의 내용에 대해 유효성 검사를 할 수 없기 때문이다.
이를 가리켜 validation relaxation 이라고 표현한다. (유효성 검사가 느슨해짐)
마지막으로 포크 이후에는 포크 이전으로 되돌릴 수 없다.
소프트 포크는 제약을 추가하는 방식으로 진행되므로, 추가된 제약에 따라 생성된 블록들이 존재하는 상황에서 포크 이전으로 돌릴 수 없기 때문이다. (유효하다고 판단이야 하겠지만, 그동안 더 엄격한 규칙에 따라온 노드들에게 보상을 해주어야 한다.)
또한 포크 이후의 규칙에 따라 생성되었던 블록들은 포크 이전의 블록의 내용을 이해하지 못할 수도 있다.
Consensus & Mining
당연한 이야기겠지만, 채굴 비용에 비해 채굴 보상이 커야만 채굴자가 계속 남아서 채굴할 것이다.
(같은 경우에도 안남는다. 열심히 채굴했는데 비용만큼만 보상을 받았다면 그 채굴한 시간에 대한 보상은 어떻게 받을까? 그 시간에 다른 일을 하는 것이 더 낫다. 최소한 인건비는 벌어야 한다.)
채굴 보상은 block reward + transaction fee, 채굴 비용은 hardware cost + operating cost 로 구성된다.
운영 비용은 전기, 네트워크, 쿨링 등의 비용을 말한다.
트랜잭션은 P2P 네트워크에 뿌려지는, 코인을 이동하는 것을 지시하는 명령이다.
이때 비트코인의 안전성은 P2P 네트워크 자체의 안전성이 아니라 블록체인 컨센서스 프로토콜에서 나온다.
(P2P는 누구나 들어오고 나갈 수 있으므로 그 자체로 안전하다고 말할 수는 없다.)
트랜잭션이 블록체인에 포함되었다는 것은 충분히 많은 confirmation 이 이루어졌다는 뜻이다. (보통은 6-confirmation)
orphan block 이 존재한다는 것은 이 블록이 속한 체인이 대세 블록체인이 되지 못했다는 뜻이고, 그 블록 안에 포함된 트랜잭션들은 유효하다고 인정받지 못한다.
비트코인의 설계 이념은 위 그림 속 3가지 개념과 밀접한 연관이 있다.
블록체인 자체의 안전성, 코인의 가치 유지, 마이닝 시스템이 얼마나 잘 유지되는지는 서로가 서로에게 영향을 끼칠 수 있다.
우선 비트코인이 의미있는 currency가 되려면 블록체인이 안전해야 한다.
블록체인은 그 자체로 currency의 거래 장부 역할을 하기 때문이다.
블록체인이 안전하려면 공격자는 컨센서스 프로토콜을 무너뜨릴 수 없어야 한다.
컨센서스 프로토콜이 견고하다는 것은 51% 공격이 불가능하다는 것과 같다.
즉, 공격자가 블록 생성에 50%가 넘는 비율을 차지하면 안된다.
이를 위해서는 신규 마이너가 계속 들어와야 한다.
순수하게 경제적 이익만을 쫓아 들어온 마이너가 들어와야 공격자의 비율이 줄어들 것이기 때문이다.
신규 마이너가 계속 들어오려면, 채굴 보상이 충분히 경제적 가치가 있어야 한다.
따라서 비트코인의 가치가 계속 유지되어야 한다.
비트코인의 가치가 계속 유지되려면 사람들이 비트코인을 계속해서 신뢰해야 한다.
비트코인을 신뢰하려면 블록체인이 안전해야하므로 다시 처음으로 돌아온 것을 알 수 있다.
이와 관련하여 비탈릭 부테린이라는 이더리움 창시자는 위 그림과 같은 트릴레마 (딜레마가 2가지 요소 사이에서의 고민점이라면, 트릴레마는 3가지 요소 사이에서의 고민점) 를 말한다.
블록체인 프로젝트는 탈중앙화, 확장성, 보안성이 모두 균형있게 해결이 되어야 한다.
만약 탈중앙화에 너무 집중에서 확장성을 잃어버려도 좋지 않고, 보안이 망가져도 역시 아무도 쓰지 않는다.
(확장성 = 여러가지 어플리케이션을 만들 수 있고, 여러 사용자들이 사용하도록 유도할 수 있는 것)
'CS > 블록체인' 카테고리의 다른 글
[블록체인] 16. Lightning Network (2) : Commitment Sign & Payment Channel (0) | 2024.12.04 |
---|---|
[블록체인] 15. Lightning Network (1) : 개요 (0) | 2024.12.01 |
[블록체인] 13. Mining (0) | 2024.10.25 |
[블록체인] 12. 비트코인 script (2) (3) | 2024.10.25 |
[블록체인] 12. 비트코인 script (1) (0) | 2024.10.25 |