로그인/ 가입하기

Solana 개발 시리즈 1 - Solana의 이해

JinseFinance

2025/01/10 10:11

따르다

출처: 덴체인 커뮤니티

솔라나 개발을 소개하는 시리즈 글입니다.

솔라나는 고유한 합의 메커니즘과 계정 모델을 통해 높은 처리량과 낮은 지연 시간을 달성하는 고성능 블록체인 플랫폼입니다.

시리즈의 첫 번째 글인 이 게시물에서는 솔라나 개발에 앞서 알아야 할 몇 가지 지식에 초점을 맞춥니다.

솔라나의 배경
블록에서 벗어나는 방법(합의 작업)
솔라나의 핵심 개념: 계정 모델, PDA, 트랜잭션 및 수수료, 클러스터링 등.

솔라나의 배경

솔라나는 2017년 아나톨리 야코벤코가 설립한 회사로, 그는 퀄컴에서 근무하던 3년 동안 거주하며 서핑을 했던 샌디에이고 북쪽의 작은 해변 마을 솔라나 비치에 헌정하는 의미로 솔라나라는 이름을 선택했습니다.

솔라나를 설립하기 전에 아나톨리는 Qualcomm, Mesosphere, Dropbox에서 다년간 근무하며 고성능 네트워킹 및 분산 시스템에 대한 폭넓은 경험을 쌓았습니다.

그는 블록체인의 확장성 병목현상으로 인해 대규모 채택 가능성이 제한되고 있다는 사실을 깨달았습니다. 분산 시스템의 시간 동기화 기술에서 영감을 받아 그는 역사 증명(PoH) 개념을 개발했습니다. 서로를 신뢰하지 않는 컴퓨터 간의 시간 동기화를 위한 것입니다.

솔라나가 어떻게 PoH를 적용하여 인증자 간의 효율적인 동기화를 달성하는지 살펴봅시다.

솔라나 컨센서스 - 블록에서 벗어나는 방법

주: 솔라나 컨센서스 알고리즘 문서는 다소 오래되었으며, 이 섹션은 심층적인 솔라나 컨센서스와 저의 이해를 참조한 것입니다.

솔라나는 지분 증명(PoS) 블록체인이며, 합의 알고리즘은 1. 블록에 대한 검증자를 선출하고 2. 다른 검증자가 해당 블록에 투표하고 충분한 투표가 누적된 후 블록이 최종 확정되는 2단계 프로세스를 따릅니다.

검증자 선출

솔라나의 프로토콜에는 시간 간격과 관련된 두 가지 중요한 단어가 있습니다: 에포크와 슬롯:

시간 슬롯(슬롯): 검증자가 블록을 생성하는 시간 단위입니다. 시간 슬롯당 하나의 블록을 생성할 수 있으며, 각 시간 슬롯은 400밀리초 동안 지속됩니다.
에포크: 각 에포크가 시작될 때 솔라나 네트워크는 서약 가중치와 이전 블록을 기반으로 무작위로 검증자(리더라고 함) 시퀀스를 선출하며, 이들은 에포크 내에서 블록 생성을 담당하고 리더 시퀀스는 기간 동안 고정된 상태로 유지됩니다. 이 기간 동안 리더 순서는 고정되어 있으며, 각 리더는 에포크당 약 2일 동안 4 슬롯을 연속으로 처리(즉, 4개의 블록을 생성)할 수 있습니다(432,000개의 슬롯 포함). 다음 에포크가 리더를 재생성할 때까지

<그림 style="text-align: 가운데;">
위 그림에서 각 색상 블록은 블록을 나타내며, 다른 색상은 서로 다른 유효성 검사된 블록을 나타냅니다.
(대부분 이해하기 어려운) 무작위 선거에 대해 자세히 설명하지 않더라도, 각 에포크가 시작될 때 검증자는 어느 슬롯에서 블록을 가져와야 하는지 알 수 있습니다.
그러나 여기서 해결해야 할 두 가지 문제가 있습니다.
검증자는 자신이 블록을 생성할 차례라는 것을 어떻게 알 수 있을까요? 이전 검증자가 다음 검증자에게 알리는 네트워크 통신에만 의존한다면, 네트워크 지연 시간(또는 이전 검증자의 탈락)으로 인해 귀중한 블록 시간을 놓칠 가능성이 높습니다(결국 블록 시간은 0.4초에 불과합니다).
하나의 블록에 최대한 많은 트랜잭션을 담는 방법. 이더리움처럼 한 트랜잭션이 다른 트랜잭션을 따르는 경우, 짧은 시간에 많은 트랜잭션을 넣을 수는 없습니다.
솔라나의 가장 중요한 혁신인 POH는 이 두 가지 문제를 해결하기 위해 설계되었습니다.
아웃 오브 더 블록
솔라나는 고성능을 위해 트랜잭션의 병렬 처리를 도입하여 트랜잭션의 정렬과 실행을 두 단계로 나누어 실행 단계를 병렬로 처리할 수 있도록 했습니다.
다른 검증자들은 트랜잭션을 검증할 때 동일한 정렬 순서를 수행하지만, 솔라나는 트랜잭션 정렬 순서를 검증할 수 있도록 하기 위해 POH 역사 증명 해시 체인 방식을 사용하여 트랜잭션의 순서를 결정합니다.
<그림 style="text-align: 가운데;">
PoH는 일련의 암호화 해시(SHA256 알고리즘)를 생성하여 이를 수행하며, 모든 해시 계산은 이전 해시 계산 시 항상 이전 해시를 사용해야 하므로 다음 해시는 항상 이전 해시 다음에 발생하므로, 마인드 데이터와 결합된 POH 해시 체인은 트랜잭션의 순서를 결정할 수 있습니다.
거래 데이터를 추가하기만 하면 됩니다. 해시를 계산하고 트랜잭션 데이터를 입력의 일부로 추가하면 트랜잭션의 순서를 결정할 수 있습니다. 그리고 이 시퀀스는 병렬 처리가 가능하고 검증 가능하며 위변조가 불가능합니다.
현재의 리더 검증자는 RPC 서버와 다른 검증자로부터 트랜잭션을 받고, 초기 검증(예: 트랜잭션 서명 및 계정 잔액 검증) 후 시퀀싱을 위해 POH 해시 체인 계산에 추가합니다. 즉, 검증 가능한 글로벌 시간 순서로 각 트랜잭션에 태그를 지정한 다음 트랜잭션을 병렬로 실행합니다. 그런 다음 병렬로 실행됩니다.
솔라나에서는 전체 트랜잭션 처리 흐름이 상호 연결된 여러 단계(트랜잭션 검증 단계, POH 정렬 단계, 실행 단계, 브로드캐스팅 단계)로 분할되어 하나의 파이프라인을 형성합니다. 서로 다른 단계는 서로 다른 CPU 코어 또는 GPU에서 서로 다른 트랜잭션 배치를 병렬로 중첩하여 처리하는 동시에 트랜잭션 검증 코어에서 다른 트랜잭션 실행 배치(뱅킹이라고 함)를 처리할 수 있습니다.
트랜잭션 실행도 병렬로 이루어지며, 트랜잭션 실행은 계정 읽기/쓰기 종속성에 따라 병렬로 배열되며, 종속성에 따라 트랜잭션을 그룹화하여 다른 스레드/CPU 코어/GPU 작업에 병렬로 투입합니다.
두 트랜잭션이 완전히 다른 계정에서 작동하거나 읽기 전용인 경우 이론적으로는 동시에 실행할 수 있지만, 쓰기 충돌이 있는 경우 데이터 불일치를 피하기 위해 순차적으로 실행해야 합니다.
위와 같이 솔라나의 블록 생성 과정을 이해했으니, 솔라나는 단일 슬롯(~400ms)에서 많은 수의 트랜잭션을 처리할 수 있습니다.
POH - 동기화된 시계
또 다른 질문은, 검증자는 차단할 차례라는 것을 어떻게 알 수 있을까요?
각 해시 연산에는 최소한의 시간이 소요되며 각 해시 계산은 이전 해시 값을 사용해야 합니다. 따라서 병렬화가 불가능합니다. 따라서 PoH 해시 체인은 시간의 경과를 증명하는 역할을 합니다.
솔라나에서는 (PoH 해시 체인의) 각 블록에 12,500개의 해시가 포함되어야 합니다. 현재 슬롯 리더는 이러한 PoH 체인(블록)을 생성할 책임이 있습니다.
사실, 검증자는 백그라운드에서 PoH 체인(거래 데이터가 없는 빈 해시 체인) 자체를 계산하지 않으며, 이전 리더(또는 다수의 이전 리더)가 블록을 게시하지 않았거나 현재 리더가 블록을 받지 못한 경우, 슬롯의 요구 해시 수만 통과하면 현재 리더가 제시간에 블록을 생성할 수 있습니다.
아래 그림과 같이 슬롯3은 오프라인 상태이고 슬롯4의 검증자가 슬롯3을 PoH 시퀀스로 채웁니다.

< span background-origin:="" background-position:="" background-repeat:="" background-size:="" 17px="" width:="" height:="" align-="">블록 검증 및 투표
블록 메타데이터 검증과 작업증명 해시 재계산을 포함하는 블록 검증 프로세스는 블록의 모든 트랜잭션을 검증 및 재생하고 원장을 업데이트합니다.
검증이 통과되면 블록에 대한 검증자의 확약이 투표로 표시되며, 검증자가 보유한 프록시 지분(코인)이 많을수록 투표의 가중치가 높아집니다.
일반적으로 검증자는 가장 무거운 체인을 선택하여 아웃블록하고 투표하며, 이전 리더의 블록이 현재 리더에게 도달하지 못하는 상황이 발생하면 포크가 발생할 수 있습니다.

포크의 경우 검증자는 각 하위 트리에 대한 총 공유당 가중치를 계산하여 가장 많은 표를 얻은 것을 선택합니다. 블록은 지분 가중치 투표의 3분의 2 이상을 받으면 유효성을 검증받습니다.
솔라나 핵심 개념
솔라나 계정
솔라나와 이더리움에서 개발할 때 느끼는 가장 큰 차이점은 계정 모델이 다르다는 점입니다.
솔라나의 계정은 리눅스 파일과 매우 유사하며, 모든 것이 계정이고 저장 단위이며 다양한 형태로 제공됩니다.
사용자 계정: 일반적으로 지갑 소프트웨어에서 생성하는 개인 키로 제어되는 계정입니다.
프로그램 계정: 실행 가능한 바이트코드(스마트 컨트랙트 코드)를 저장하는 데 사용되는 계정입니다.
데이터 계정: 사용자가 보유한 특정 토큰의 수와 같은 상태 정보를 저장하는 계정입니다.
네이티브 프로그램 계정: 네트워크의 다양한 핵심 기능을 수행하는 사전 배포된 특수 프로그램 계정입니다. 여기에는 시스템 프로그램, 투표 프로그램, BPF 로더 등이 포함됩니다.
<span;) 10px;10px;/ 40px;no-repeat ; height: 30px;width: 100%; margin-bottom:-7px;border-radius:5px;'
상태가 없고 읽기 전용인 솔라나의 중간 프로그래머 계정(즉, 스마트 컨트랙트)은 데이터/상태를 저장하지 않습니다. 데이터는 별도의 데이터 계정에 저장됩니다.
솔라나 컨트랙트에서 함수를 호출할 때, 함수에 사용된 데이터 계정을 전달해야 합니다. 상호 의존성이 없는 트랜잭션을 동시에 실행하는 것은 쉽습니다.
EVM에 대해 조금이라도 알고 계신다면 상태 데이터도 컨트랙트에 저장된다는 것을 알고 계실 것입니다. 카운터를 예로 들어보겠습니다. 솔라나에서는 프로그램 코드를 저장할 프로그램 계정과 카운터 값을 저장할 계정 두 개를 만들어야 합니다.
렌트는 계정이 활성 상태를 유지하기 위해 최소 잔액을 유지하도록 요구하여 상태 부풀림을 줄이는 솔라나의 방법입니다. 임대를 통해 네트워크는 결국 사용하지 않거나 잔액이 부족한 계정을 회수할 수 있습니다. 계정이 2년치 임대료에 해당하는 최소 잔액을 유지하면 임대료가 면제됩니다.
솔라나의 계정은 동시 실행의 이점 외에도 프로그램 재사용성을 제공하도록 설계되었으며, 이더에 동일한 ERC20 코드가 다수 포함되어 있습니다.
솔라나는 새 토큰을 생성할 때 스마트 컨트랙트를 다시 배포할 필요가 없다는 점에서 다릅니다. 대신 토큰 수, 토큰 이름, 토큰을 더 많이 발행할 수 있는 사람 등을 정의하는 채굴 계정이라는 새 계정이 생성됩니다.
프로그램 파생 주소(PDA: 프로그램 파생 주소)
프로그램 데이터를 보유하는 데 사용되는 계정은 PDA이며,
일반 사용자 계정에는 ed25519 타원 곡선의 한 점에 해당하는 공개 키/주소와 계정 수정 권한을 증명하는 서명에 사용되는 개인 키가 있습니다. (권한).
프로그램 파생 주소(PDA)는 범프를 사용하여 곡선 외부에서 생성된 계정으로(출력이 곡선 값에서 벗어나더라도), PDA에는 부모 ID, 시드 세트 및 점프 값의 세 가지 주요 구성 요소가 필요합니다. 시드는 문자열 배열로, 일반적으로 프로그램에서 특정 시드와 연결된 상태 변수를 사용하여 해시 테이블과 같은 데이터 구조를 만들기 위해 설정하는 경우가 대부분입니다. 를 사용하여 해당 PDA를 생성합니다.
해당 PDA를 파생하는 프로그램이 소유자이며 해당 프로그램만 PDA의 데이터를 수정할 수 있습니다.

< span background-origin:="" background-position:="" background-repeat:="" background-size:="" 17px="" width:="" height:="" align-="">트랜잭션
솔라나 네트워크에 보내는 트랜잭션은 네 가지 부분으로 구성됩니다.
하나 이상의 지침(instruction)
어떤 계정의 계정 배열 (account_keys)
하나 이상의 서명 (signatures)
최근 블록해시 (recent_ 블록해시)
디렉티브는 Solana에서 가장 작은 실행 로직 조각입니다. 지시어는 실행 절차, 관련된 모든 계정 및 운영 데이터를 지정합니다. 지시어는 프로그램을 호출하여 상태를 업데이트하고(예: 토큰 프로그램을 호출하여 내 계정에서 다른 계정으로 토큰을 전송), 프로그램은 지시어의 데이터를 해석하여 지정된 계정에서 작업을 수행합니다.
디렉티브는 이더리움 스마트 컨트랙트의 함수 호출과 유사합니다.
트랜잭션에서 여러 명령어를 실행하는 것은 원자적이며, 모든 명령어는 함께 성공하거나 실패합니다.

솔라나는 트랜잭션의 유효성을 나타내기 위해 가장 최근의 블록해시를 사용하지만, 트랜잭션을 생성하고자 할 때는 클러스터에서 가장 최근의 블록해시를 가져와서 유효한 트랜잭션을 생성하게 됩니다. 트랜잭션은 가장 최근 블록해시 이후 150블록 동안 유효합니다. 변경 시간이 초과되면 트랜잭션을 다시 시작해야 합니다.
솔라나에는 이더 트랜잭션에 대한 논스 개념이 없습니다.
솔라나 트랜잭션 수수료는 트랜잭션에 포함된 서명 수(lamports_per_signature)와 기본 수수료와 관련이 있다는 점에서 이더의 가스 메커니즘과 매우 상이합니다. >현재 서명당 0.000005 SOL(5천 램프포트)로 설정되어 있으며, 이는 네트워크 자원을 사용할 수 있는 권리에 대한 일회성 수수료로 트랜잭션 실행에 실제로 얼마나 많은 자원이 사용되는지(또는 트랜잭션이 전혀 실행되지 않는지)에 관계없이 네트워크에 선불로 지급되며, 수수료의 50%는 블록을 생성한 검증 노드에 지급되고 나머지 50%는 소멸됩니다.
거래의 우선순위[선택적 수수료]를 높이고자 하는 경우, "계산 단가"를 설정할 수 있습니다. 이 가격은 계산 단위 제한과 함께 사용되어 트랜잭션의 우선순위 비용을 결정합니다.
기본 계산 단위 제한은 명령당 200,000 CU이며, 대규모 계산의 경우 최대 140만 CU까지 설정할 수 있습니다. Solana 트랜잭션은 사전에 지정된 수의 CU(컴퓨팅 유닛)를 요청하며, 이 수를 초과하면 트랜잭션이 실패합니다.
또한 솔라나 트랜잭션에는 패킷 크기 제한이 적용되며, 솔라나 네트워크는 UDP를 통한 클러스터 정보의 빠르고 안정적인 전송을 보장하기 위해 IPv6 MTU 크기 제약과 일치하는 최대 전송 단위(MTU) 크기 1280 바이트를 따릅니다. 필요한 헤더(IPv6의 경우 40바이트 및 8바이트 조각 헤더)를 계산한 후에도 패킷에 1232바이트를 사용할 수 있으며 서명과 메시지의 조합은 이 제한을 초과할 수 없습니다.
솔라나 클러스터
솔라나 클러스터는 트랜잭션을 처리하고 자체 원장 데이터를 유지하기 위해 함께 작업하는 검증자 그룹입니다. ledger).솔라나에는 각각 특정 목적을 가진 여러 가지 클러스터가 있습니다.
클러스터는 이더의 여러 네트워크에 해당합니다.
로컬 호스트< /span>: 기본 포트 8899의 로컬 개발 클러스터입니다. 솔라나 명령줄 인터페이스(CLI)에는 내장된 테스트 유효성 검사기가 내장되어 있어 에어드랍이나 속도 제한 없이 개별 개발자의 필요에 맞게 사용자 지정할 수 있습니다
Devnet (Devnet): 솔라나를 테스트하고 실험할 수 있는 가치 없는 샌드박스 환경
Testnet 솔라나 핵심 기여자들이 새로운 업데이트와 기능을 실험할 수 있는 테스트 사이트로, 메인 네트워크에 적용하기 전에 테스트할 수 있습니다. 또한 개발자가 성능 테스트를 수행할 수 있는 테스트 환경으로도 사용됩니다
메인넷 베타: 라이선스가 필요 없는 실시간 클러스터로, 다음이 가능합니다. 실제 트랜잭션이 발생합니다. 사용자, 개발자, 토큰 보유자, 검증자가 매일 상호작용하는 "진짜" 솔라나입니다

각 클러스터는 독립적으로 실행되며 다른 클러스터를 전혀 인지하지 못합니다. 각 운영 환경의 무결성을 보장하기 위해 잘못된 클러스터로 전송된 트랜잭션은 거부됩니다.
요약
이 문서에서는 계정 모델, 블록아웃 메커니즘, 트랜잭션 표기 구조 등 Solana의 핵심 개념을 소개했습니다.
이러한 기본 개념을 이해했으니 이제 솔라나를 직접 사용해 애플리케이션 개발을 시작할 차례입니다.
기사 참조
솔라나 작동 방식 - 작동 원리
솔라나 작동 방식 - 작동 원리
솔라나 컨센서스 자세히 알아보기 - 포크에서 최종 확실성까지