[Besu] 논문요약 : Permissioned Blockchains : A Comparative Study (2)

Hyperledger Besu의 아키텍쳐

이 전에, Besu는 이더리움 프로토콜을 구현한 이더리움 클라이언트라고 이야기했었다. 이 위에 Besu는 EEA의 프로토콜을 구현함으로써 이더리움에 프라이빗 트랜잭션, 허가와 같은 기능들을 추가로 확장했다. 대부분의 Besu의 구조적인 구성과 개념이 이더리움을 따르기 때문에, 이더리움에 대한 설명도 같이 하고자 한다. 이더리움은 프로토콜이기 때문에, 단 하나의 구체적인 구현이 있는 것이 아니다. Go-Ethereum 를 표준으로 치는 경우도 있지만, Open Ethereum과 같이 다른 구현도 존재한다).  Besu는 다른 이더리움 구현을 fork해온 것이 아니다. JAVA로 이더리움 프로토콜을 자체적으로 구현한 것이다. 때문에 비슷한 작업을 하고 있던 조직들도 Besu를 주목하고 있다.             

• 0. 노드
• 1. 계정
• 2. 장부
• 3. 스마트 컨트랙트
• 4. 이더리움 가상머신
• 5. 네트워크와 상호작용
• 6. 허가

 

그림 3.9 Besu 네트워크 아키텍쳐

 

0. 노드

Besu 네트워크는 완전히 동일한 피어 노드에 의해 실행되고, 각 노드는 Besu 엔터프라이즈 이더리움 클라이언트 인스턴스를 실행한다. 피어들 간의 통신은 완전히 P2P 방식으로 진행되고, 약간의 중앙화(탈중앙화의 반대)나 다른 노드 타입을 허용하지 않는다. 이 노드들은 모든 트랜잭션과 함께 장부를 저장하고 있는 전체 블록체인을 저장하고, 풀노드(Full Node)라고 부른다. 풀노드들은 모든 트랜잭션을 순차적으로 실행('빠른 동기화' 기능은 지원하지 않는다)해야하기 때문에, 그들은 가장 최신의 world state를 갖는다. 네트워크에 새로운 풀노드는 다른 피어에게 블록을 요청해서 이 world state를 제거할 수 있다. 하지만, 풀노드는 오직 가장 최신의 world state만 유지하고 있기 때문에, 풀노드는 이전 블록의 state를 빠르게 조회할 수는 없다(현재 head 앞 블록의 잔고, 스마트 컨트랙트 state 등).

 

비록 앞에서 완전히 동일한 노드들이 네트워크를 구성한다고 했지만, 약간의 미묘한 차이가 있다. 아카이브 노드가 추가적으로 풀노드의 확장 개념으로 존재하는데, 이 노드들은 각 블록의 각의 모든 중간 world state를 저장해서, 다시 트랜잭션들로 다시 계산하여 이전의 world state를 가져올 필요가 없게끔한다. 대신 아카이브 노드는 더 많은 저장공간이 필요하다. 아카이브 노드는 풀노드의 확장 개념이므로, 풀 노드의 모든 기능을 제공한다. 

 

또 다른 흥미로운 주제는 조직과 노드의 관계이다. Besu에서는 '조직'의 개념이 없기 때문에 관계는 굉장이 단순하다. 모든 노드들이 그들 자신의 public / private키를 가지고 자신의 신원을 증명한다. 이것은 네트워크에 참여함에 있어 조직이 훨씬 유연함을 의미한다: 작은 조직은 하나의 노드를 이용해 참여하고, 큰 조직은 여러 개의 노드를 이용해 참여할 수도 있다. 

 

그림 3.10 Besu 구성요소 및 개념의 관계 다이어그램

 

네트워크 생성

Besu는 네트워크를 생성하는 과정 역시 굉장히 단순하다. 이 과정은 크게 3개의 단계를 포함한다.

1. 제네시스 파일을 설정한다. 이것은 제네시스 블록을 만드는데 사용된다.
2. 각 노드별 설정이 config.toml에 설정되어야 한다.
3. 마지막으로 노드를 실행한다.

제네시스 설정 파일은 비교적 작고, 전체 네트워크에 적용할 다양한 설정들을 포함하고 있다. 이 중 허가형 네트워크에서 주요한 4가지 설정값들을 살펴보자.

• config : 네트워크에서 사용할 합의 알고리즘에 대해 정한다.
• gasLimit : 블록의 최대 가스량을 정한다. 기업에서는 보통 gas 없이 사용하기 때문에, 최대 값으로 설정한다.
• contractSizeLimit : contract의 사이즈를 제한한다. 기본 24KB로 설정되어 있다. 필요(앱 구현)에 따라 늘릴 수 있다.
• alloc : 스마트 컨트랙트나 접근할 계정과 초기 잔고를 미리 정의하는데에 사용할 수 있다.

 

그림 3.11 Besu 네트워크를 생성하고 유지하는 전형적 플로우

 

네트워크를 생성했으니 다음, 각 노드들이 설정되어야 한다. 이 과정 역시 매우 간단하다.  거의 모든 기능들을 스위치 처럼 온-오프로 설정할 수 있다. rpc-http-enabled, rpc-ws-enabled, graphql-http-enabled 옵션들과 호스트, IP 옵션은 이 노드가 기능을 JSON-RPC를 통해 제공할지, WebSocket을 통해 제공할지, GraphQL로 제공할지 선택할 수 있도록 해준다. Metrics-enabled는 Prometheus 같은 어플리케이션이 블록체인의 메트릭스를 주기적으로 조사해 높이, 마지막 블록 번호, 연결된 피어, 피어별 연결된 피어 수 등과 같은 정보를 볼 수 있도록 허용한다. permissions-nodes-config-file을 통해 노드별로 다른 계정과 노드의 접근을 제한할 수 있다. min-gas-price는 특별히 허가형 블록체인 네트워크를 위해 중요한데, 0으로 설정하지 않으면 일정량의 가스를 만족하지 않으면 트랜잭션을 실행하지 않을 것이다. bootnodes는 의미를 제대로 아는것이 중요하다. 노드를 실행하면, 네트워크에 연결되어 있는 어떤 노드 중 하나를 참조하여 현재 실행하려는 노드가 연결할 피어에 대한 정보를 얻는다. 이름이 노드의 종류 같아서 노드의 부팅을 도와주는, 네트워크의 문지기처럼 중앙화된 형태를 상상하는 경우가 간혹 있지만 헷갈리지 말자. bootnodes로 설정하는 노드도 다른 노드와 똑같은 노드이다. 결국, 피어는 각자 설정한 부트노드를 네트워크의 어떤 노드로던지 바꿀 수 있다.

 

만약 피어의 최소 숫자(합의 알고리즘에 따라 다르다)를 찾으면, 네트워크가 동작되기 시작한다. 얼마나 다양한 조직들이 피어의 관점으로 네트워크를 통해 협업할 수 있는지 그림 3.12에서 보여준다. 조직들은 구분이 잘 되라고 색칠한 것이지, 기술적으로 다름을 나타내지 않는다. 이전에도 말했지만 Besu에는 조직이라는 컨셉 자체가 없다. 하지만 기관에서 하나의 노드를 메인 부트 노드로 사용하면서, 다른 기관의 네트워크와 연결하는 방법도 사용할 수가 있다. 그림 3.12에서 초Org3의 경우가 그러하다. 이 다이어그램을 통해서, 조직이 그들의 bootnode를 정하는 데에 있어, 굉장히 유연하며 여러개의 조직에 걸쳐 여러개의 노드를 자신의 bootnode로 설정할 수 있음을 확인할 수 있다. 사실 네트워크에 연결된 하나의 노드에만 연결되어 있어도, peer discovery를 통해 네트워크 상의 모든 노드와 통신할 수 있다.

 

그림 3.12 세 개의 기관이 네트워크를 구성하는 예시

 

 

1. 계정

위에서는 노드가 무엇인가, 어떻게 그들끼리 서로 연결하고, 어떻게 네트워크를 구성하는가에 대해서 설명했다. 하지만, 이 노드들이 트랜잭션을 생성하고 사인하는데에 참여하는 것은 아니다. 그들의 유일한 역할은 장부를 계속해서 추적관리하고, 블록을 만들며 트랜잭션을 검증하는 것이다. 트랜잭션은 계정에 의해 생성되고 사인된다. 사실, 이러한 계정들은 네트워크와 완전히 무관할 수도 있는 개체들이다. 트랜잭션은 계정과 계정 사이에 일어난다. 요약하면, 노드들이 네트워크의 인프라에 불과하며, 계정들이 인프라 위에서 실제 활동을 하는 개체들이라는 사실이다. 계정에는 두 종류가 있다. EOA(Externally Owned Accounts)와 SCA(Smart Contract Account)가 있다. 두 타입의 계정 모두 스마트 컨트랙트를 활용하여 상호작용할 수 있다. 

 

EOA (Externally Owned Account)

EOA는 개인이나 그룹이 가질 수 있는 전형적인 타입의 계정이다. 기본적으로 EOA는 한 쌍의 공개키와 개인키이며, 완전히 블록체인 네트워크의 바깥에 있다. 그러므로, 계정은 누구나 생성할 수 있고, 네트워크가 비허가형이거나, 액세스 권한이 있는 경우에는 이더리움 기반 네트워크에서 사용할 수 있다. 공개키-개인키 쌍은 타원곡선 암호를 통해 생성되며, 이것은 RSA(Rivest-Shamir-Adleman)에 비해 더 빠르고 안전한 방법이다.

 

계정을 생성하기 위해서, 먼저 0과 2²⁵⁶ 사이의 정수를 사용하여 개인 키를 임의로 생성한다. 이 방법으로 약 10⁷⁷개의 개인키를 생성할 수 있으며, 이는 우주에서 관측 가능한 원자량보다 100배~1000배 밖에 적지 않은 수치이다. 같은 개인키를 갖게 되는 것이 얼마나 낮은 확률인지 알 수 있다. 개인 키는 공개 키를 생성하는 데 사용된다. secp256k1 알고리즘은 공개 키를 계정의 주소를 나타내는 하나의 정수로 압축하며, 이 정수는 보통 16진수 문자열로 표현된다. 이 공개 키와 개인 키를 가지고 PKI가 아닌, ECDSA(Elliptic Curve Digital Signature Algorithm)을 사용하여 트랜잭션에 서명한다. 결론적으로, 참여자들은 공개 키를 서로 공유할 필요가 없다. 이것이 왜 공개키가 사전에 장부에 등록되지 않고도, EOA가 오프체인에서 생성될 수 있는 지를 설명한다.

 

SCA (Smart Contract Account)

SCA는 EOA가 스마트 컨트랙을 사용할 때 자동으로 생성된다. SCA는 또 그 자신만의 주소를 갖는데, 이것은 스마트 컨트랙트를 생성한 EOA의 주소와 nonce값을 인코딩하여 keccak256으로 생성한다. SCA 주소는 계정의 주된 식별자이며 다른 계정이 이 주소를 찾아 상호작용하기 때문이다.

 

키 쌍 구조

비록 Besu의 모든 각각의 노드와 계정이 공개 키/개인 키 쌍을 하나씩 가지고 있는 것 처럼 보이지만, 혹시 상위의 조직이 사인을 할 수 있는 여지가 있는지 확인해 볼 필요가 있다. Besu는 ECDSA로 공개 키/개인 키 쌍을 사용한다. 공개 키/개인 키는 하나의 텍스트이며, 개인 키는 256비트의 정수에 대응하는 64비트 16진수의 정수이다. 공개 키는 512비트의 정수에 대응하여 secp256k1의 타원 곡선을 이용해 생성된다. 그리고 이 키들은 패브릭에서 사용되는 인증서와 다르게 항상 숫자로 사용된다. Besu에서 키들은 인증서로 포장되어 있지 않기 때문에, 상위 조직에 의해 사인이 될 수 없다.

 

 

2. 장부(Ledger)

Besu에 데이터가 어떻게 저장되는지 이해하려면, 도큐먼트가 굉장히 제한적이기 때문에 소스코드를 살펴볼 수 밖에 없다. 소스코드를 보면 StorageProvider라는 파사드를 사용하는 것을 알 수 있다.

 

// 3.1 StorageProvider
public interface StorageProvider extends Closeable {
	BlockchainStorage createBlockchainStorage ( ProtocolSchedule protocolSchedule );
	WorldStateStorage createWorldStateStorage ( DataStorageFormat dataStorageFormat );
	WorldStateStorage createPrivateWorldStateStorage () ;
	GoQuorumPrivateStorage createGoQuorumPrivateStorage () ;
}

 

첫째로, BlockchainStorage는 블록을 저장하는데에 사용된다. 블록의 해시와 본문을 제공해서, 블록을 저장할 때 필요한 put-연산 기능을 제공한다. 이 블록들은 외부의 키-밸류 데이터베이스를 사용해 저장할 수 있다. 기본값으로 이것은 rocksdb로 설정되어 있지만, 다른 키-밸류 데이터베이스를 구현해 사용할 수 있다. BlockchainStorage는 빠르게 블록을 조회할 수 있도록, 블록 번호에서 블록 해시로의 맵핑 또한 저장하고 있다. 

 

두번째로, WorldStateStorage를 통해 world state을 저장한다. 이 world state은 트라이 데이터 구조를 활용하여 저장된다. 이 역시 key-value 저장 프로그램을 사용할 수 있다. 기본값으로, 약간 변형된 Bonsai Trie 데이터 구조가 사용됐다. 이것을 수정하기 위한 값이 숨겨져 있는 것으로 보아 권장되는 데이터 구조라고 생각된다. 사실 중요한 것은 이 데이터 타입에 어떤 종류의 데이터가 저장되는가이다. 뒤에 설명하겠지만 world state는 계정 주소에서 계정 state로의 매핑 정보 역시 포함하고 있다. 스마트 컨트랙의 주소(해시)에서 코드로의 매핑 정보역시 포함하고 있다. 사실, 이 코드 자체가 스마트랙이다. 마지막으로 world state는 계정의 해시에서 계정의 저장공간까지의 매핑 역시 포함하고 있다. 저장공간은 스마트 컨트랙의 유니크한 key-value 매핑을 참조한다.

 

// 3.2 Storing of World State in Besu
public interface WorldStateStorage {
	interface Updater {
		Updater putAccountStateTrieNode ( Bytes location , Bytes32 nodeHash , Bytes node );
		Updater putCode ( Hash accountHash , Bytes32 nodeHash , Bytes code );
		Updater putAccountStorageTrieNode ( Hash accountHash , Bytes location , Bytes32 nodeHash ,
			Bytes node );
	}
}

 

세번째로, createPrivateWorldStateStorage()라는 함수는 같은 데이터 타입(WorldStateStorage)을 반환한다. 이것을 통해서, 우리는 프라이빗 데이터는 프라이빗 데이터 만의 world state를 가지고 있고, 네트워크의 world state와는 완전히 분리되어 있음을 알 수 있다. 마지막 함수인 createGoQuorumPrivateSotrage()로 Besu의 world state가 GoQuorum이라는 또다른 엔터프라이즈 이더리움 클라이언트의 형식과 동일한 형식으로 저장할 수 있음을 알 수 있다. 그림 3.13이 Besu 장부의 단순화된 모습을 보여준다.

 

그림 3.13 장부 안에 저장된 데이터의 시각화 자료

 

계정 구조

이전에 이더리움 백서를 기반으로 잠깐 계정에 대해 설명했지만, Besu의 계정이 이더리움 프로토콜과 개념적으로 완전히 동등하지는 않다. 그러므로 Besu의 계정이 어떻게 장부에 저장이 되는지, accountState는 무엇인지 알아볼 필요가 있다. 다음 3.3은 AccountState의 단순화된 인터페이스를 보여준다.

 

// 3.3 Account State
public interface AccountState {
	Hash getAddressHash () ;
	long getNonce () ;
	Wei getBalance () ;
	default boolean hasCode () ;
	Bytes getCode () ;
	Hash getCodeHash () ;
	UInt256 getStorageValue ( UInt256 key );
}

 

이 코드 조각에서, 모든 계정은 트랜잭션을 하기 위한 주소인 AddressHash를 위한 필드를 가지고 있음을 알 수 있다. 그리고 모든 계정이 Nonce와 연결지어져 있다. 나중에 살펴보겠지만, 모든 트랜잭션은 하나의 EOA에 의해 사인 및 초기화된다. 모든 EOA의 트랜잭션은 Nonce 값을 가지며, 이 값이 계정의 Nonce 보다 커야 트랜잭션의 유효성을 검증하고, 이중지출을 방지할 수 있다. SCA의 nonce는 오직 계약이 새로운 (다른) 계약을 실행할 때만 증가한다. 또 계정은 암호화폐와 관련해 Balance를 Wei 단위로 가지고 있음을 알 수 있다. 물론 허가형 네트워크에서는 대부분 불필요한 요소이다. 계정의 코드와 저장소에 접근할 수 있는 기능 역시 제공하고 있음을 알 수 있다. 물론 계정 내부가 아닌, 따로 저장되어 있는 정보에 계정의 해시를 이용해 접근하는 방식이다. 

 

위의 인터페이스는 EOA와 SCA에 공통으로 적용된다. 하지만 EOA는 어떤 코드도, (키-값)저장소도 가지고 있지 않다. 코드와 스토리지는 스마트 컨트랙에 대해서만 존재한다. 그러므로, 우리는 EOA와 SCA의 구조적 차이를 그림 3.14와 같이 시각화할 수 있다. 회색의 항목은 비어있거나 사용하지 않거나, 허가형 설정을 위해서는 무관한 항목들이다. 

 

그림 3.14 EOA와 SCA의 구조적 차이

 

트랜잭션 구조

이젠 장부의 구조, 계정의 의미와 구조에 대해 명확히 알고 있으니, 이제 계정들이 어떻게 장부에 트랜잭션을 통하여 수정하는지 알아볼 수 있다. 트랜잭션은 3.4에 있는 함수들을 구현한다. 이 인터페이스로 Besu가 트랜잭션 타입을 메시지 콜과 계약 생성으로 구분하고 있음을 알 수 있다. 

 

// 3.4 Transaction Structure
public interface Transaction {
	Hash getHash () ;
	long getNonce () ;
	Quantity getGasPrice () ;
	Optional < Quantity > getGasPremium () ;
	Optional < Quantity > getFeeCap () ;
	long getGasLimit () ;
	Optional <? extends Address > getTo () ;
	Quantity getValue () ;
	BigInteger getV () ;
	BigInteger getR () ;
	BigInteger getS () ;
	Address getSender () ;
	Optional < BigInteger > getChainId () ;
	Optional < Bytes > getInit () ;
	Optional < Bytes > getData () ;
	Bytes getPayload () ;
	TransactionType getType () ;
}

 

모든 트랜잭션은 식별과 nonce를 위해 자신 고유의 해시를 갖는다. 트랜잭션의 nonce는 트랜잭션을 생성한 사람의 nonce, 즉 계정이 생성한 트랜잭션의 개수를 가리키는 긴 숫자이다. 만약 이 트랜잭션의 nonce가 계정의 nonce 보다 작다면, 트랜잭션은 이전 블록이나 같은 블록의 다른 트랜잭션에 이미 포함된 트랜잭션 전에 실행되어야 하므로 검증되지 않는다. 모든 트랜잭션이 순서에 맞게 정렬되어 있기 때문에, 나중에 도착한 트랜잭션은 이미 포함된 트랜잭션보다 먼저 실행될 수 없다(Fork의 경우 제외). 가스는 보통 허가형 네트워크에서는 설정하지 않으므로 GasPremium, FeeCap, GasLimit, Value는 빼기로 한다. 게다가 모든 트랜잭션은 사인 과정의 일부로서 ECDSA에 의해 생성된 V, R, S-값을 포함한다. Sender 항목은 트랜잭션을 생성하는 계정의 주소를 저장한다. 이 값들은 V, R, S-값에서 파생되기 때문에 Sender가 SCA가 아닌 EOA를 참조하는 것이 분명하다. ChainId 역시 재진입 공격을 방지하기 위해 V-값에서 파생된다.

 

스마트 컨트랙을 호출하기 위해서, 송신자는 To 항목에 SCA 주소와 Payload 항목에 함수 호출, 매개변수를 제출한다. 계약 생성 트랜잭션은 To 항목에 수신자의 주소를 적을 필요가 없는데, 왜냐하면 이 주소는 송신자의 주소와 nonce에 의해 생성되기 때문이다. 계약 생성 트랜잭션은 스마트 컨트랙 호출과 대비되게도, 인자 대신 Payload 항목에 스마트 컨트랙의 바이트 코드를 지정한다. Init 항목은 트랜잭션이 스마트 컨트랙을 생성한다면 Payload 항목을 가리키고, 메시지 콜이라면 비어있다. 마찬가지로 Data 항목은 트랜잭션이 메시지 콜이라면 Payload 항목을 가리키고, 스마트 컨트랙이라면 비어있다. 마지막으로, Type은 열거형 타입을 가리키며, 최근에는 EIP1559로 설정되어있다. 이것은 새로운 유형의 트랜잭션의 순방향 호환성에 사용된다. 두 가지 유형의 거래에 대한 개요는 그림 3.15를 참고하자.

 

그림 3.15 두 트랜잭션 종류(컨트랙 생성과 메시지 콜)의 구조적 차이

 

 

3. 스마트 컨트랙트

위에서 봤듯이, 우리는 스마트 컨트랙(혹은 SCA)가 3개의 주요 구성요소로 이루어져 있음을 보았다: (주소, nonce를 포함한)account state, 스마트 컨트랙 바이트코드, 스마트 컨트랙 저장소. 이 구성요소들이 장부 위에서 어떻게 저장되고 어떻게 설 연결되는지도 알아보았다. 비록 각 스마트 컨트랙이 저장(혹은 state)의 관점에서 독립되어 있지만, 스마트 컨트랙은 하나의 계약이 다른 계약을 호출할 수 있다는 점에서 구성 가능하다. 하지만 구성된 스마트 컨트랙이라도 EOA에 의해 호출되어야 하고, 이벤트를 기반으로 하여 자기 자신을 호출할 순 없다. 이 섹션에서는 스마트 컨트랙이 어떻게 생성되고, 유지되는지 개념적인 단계에서 집중해 알아보자.

 

스마트 컨트랙 쓰기

이전에 봤듯이, 스마트 컨트랙은 바이트코드를 이용하여 생성된다. 바이트 코드라는 용어는 통상적으로 컨트랙 생성 바이트 코드를 지칭하는데, 이는 스마트 컨트랙의 생성자를 포함한다. 다음, 이 바이트 코드는 실제 장부에 저장되는 형태이자 트랜잭션을 실행하는 런타임 바이트코드로 번역된다. 스마트 컨트랙을 장부에 올리기 위해서, (위 그림 3.15에서 봤던)컨트랙 생성 바이트코드를 포함하는 컨트랙 생성 트랜잭션이 제출되어야 한다. 개발자에게 보통 런타임 바이트코드에 대한 지식이 필수는 아니지만 혹시 발생할 수 있는 혼란을 줄이기 위해서 알아두면 좋다.

 

운 좋게도, 바이트코드는 대부분의 경우 개발자가 작성하지는 않는다. 하지만, 고급 언어를 컴파일하여 생성된다. 최근에는 EVM이 Solidity, Vyper, Yul(+) 등의 언어를 지원하고 있다. 이 언어들은 DSL이다. 가장 널리 사용되는 언어는 Solidity이다. Solidity는 JavaScript의 영향을 크게 받은 받은 정적 타입 언어이다. Solidity 스마트 컨트랙은 추가 파일에 정의된 다양한 라이브러리를 사용할 수 있다. Vyper는 또 다른 DSL언어로, 간결성, 수정 가능성, 보안 등의 목적을 가지고 탄생했다. Vyper는 코드베이스가 다른 사람들에 의해 철저하게 검증되어야할 필요가 있을 때 사용하면 좋은 언어이다. 예를 들면 컨소시엄에 참여한 기관간에 서로를 완전히 신뢰할 수 없을 때 사용하면 좋다. 하지만 이것은 Solidity가 수정 불가능하다는 의미는 아니다. 이것은 단지 Solidity로 작성된 스마트 컨트랙이 Vyper가 엄격한데에 비해 더 유연할 수 있다는 것이다. 세번째로 Yul(+)은 굉장이 로우 레벨의 언어이고, 자신들의 구현을 보다 최적하고 싶은 경우 사용할 수 있다.

 

스마트 컨트랙이 앞서 말했던 언어들로 쓰여지면, 해당 언어의 컴파일러가 컨트랙을 바이트 코드로 번역한다. 이 바이트코드는 (접근 허가가 있다면)어떤 계정이던지 네트워크에 제출할 수 있는 컨트랙 생성 트랜잭션을 포함한다.

 

스마트 컨트랙 유지하기

스마트 컨트랙이 블록체인 그 자체에 배포되어 있다는 사실 때문에, 그것들은 배포가 되고 나면 수정될 수 없다. 이 것은 스마트 컨트랙 개발자에게 또다른 과제이다. 이 방해물은 DelegateCall() 메소드를 이용하면 부분적으로 극복할 수 있다. 스마트 컨트랙 A가 이 함수를 호출하면, 다른 스마트 컨트랙의 함수(B)를 호출할 수 있게 된다. 함수의 실행 결과 생긴 변화는 A의 스마트 컨트랙의 키-값 저장소에 저장된다. 개발자들은 DelegateCall() 메소드를 다른 스마트 컨트랙에 실제 구현을 작성하고, 스마트 컨트랙을 대리로 배포할 때 사용해왔다. OpenZeppelin은 배포하고 업그레이드 가능한 스마트 컨트랙을 수정하는 것을 간편하게 하는 플러그인을 만들었다. 하지만 이것이 문제에 대한 완벽한 해답은 아니다. 만약 스마트 컨트랙이 하나의 개인에 의해 업그레이드가 된다고 하면, 이것은 신뢰와 남용 위험의 문제를 야기한다. 이것은 실제 변경하기 전에, 여러개의 EOA가 참조된 컨트랙의 주소를 업데이트하도록 요구함으로써 극복할 수 있다. 만약 컨트랙에서 버그가 발생했다면, SCA 저장소가 이미 바뀌었을 것이고, 이것을 복구하기는 쉽지 않을 수도 있따. 131개의 스마트 컨트랙의 연구 논문과, 150명이 넘는 이더리움 개발자를 대상으로 한 설문결과를 통해 이러한 이슈에 대해 어떻게 대응하는지 조사했다. 36%의 응답자는 이 대리-접근 방법을 사용했고, 반면에 대다수는 그냥 새로운 컨트랙을 배포했다. 새로운 컨트랙을 배포한 대다수의 개발자들은, Selfdestruct()함수를 사용해 이전 컨트랙을 폐기했다.

 

 

4. 이더리움 가상머신

Besu는 EVM을 트랜잭션을 실행하는 엔진으로 사용한다. EVM은 준-튜링완전이라고 하기도 하는데, 이것은 가스 제한과 실행 시간 때문이다. 보통 EVM은 GasCalculator를 사용하여 코드 실행에 사용된 가스의 양을 추적한다. 가스가 다 떨어지면, 트랜잭션ㅇ실행은 취소되고, 변경된 state는 롤백된다. 이 전에 언급했듯이, 이러한 한계는 가스를 0으로 설정하고, 가스 제한을 최대값으로 설정하는 허가형 설정을 하면 사라진다. 가스 제한이 거의 무한에 가깝기 떄문에 EVM은 튜링완전이라고 이야기할 수 있다. 하지만 가스가 필요없는 허가형 설정에서도, 만약 누군가가 허가형에서 가스비를 합리적으로 낮게 설정한다면, 어설프게 작성된 스마트 컨트랙이 전체 네트워크의 속도를 낮추지는 않을 것이다.

 

Besu의 소스코드를 보면, EVM 구현이 스택 기반의 아키텍쳐를 하고 있음이 명백해진다. 이것은 이더리움의 기술문서에 제안된 컨셉과 비슷하다. 이 EVM은 EVM이 실행할 수 있는 연산의 리스트인 OperationRegistry를 정의한다. 이 리스트에는 간단한 Push, Pop 연산을 포함해서 DelegateCall과 같은 복잡한 연산도 있다.

 

Besu에서의 트랜잭션은 메시지 콜이거나 컨트랙 생성 트랜잭션이다. 우리는 이 두 가지 트랜잭션이 같은 인터페이스를 통해 구현됨을 알 수 있었다. 이 두가지 트랜잭션이 메세지, 즉 장부에 요청한 변화라는 결과를 가져온다. 메세지들은 Besu에서 MessageFrame의 형태로 표현되는데, MessageFrame은 "메세지와 관련된 모든 state의 컨테이너 객체"이다. 관습적으로, 이것은 MessageFrame은 global state(WorldsState, blockchain), 스택 아키텍쳐(program counter, memory, stack) 등 여러 개(44)의 private 항목을 포함하고 있음을 의미한다. Besu의 EVM 구현 전부를 설명하는 것은 너무 기술적이다. 그러므로 그림 3.16, 그림 3.17의 요약된 그림을 참고하면 좋을 것이다.

 

그림 3.16 Besu의 EVM 구현

 

그림 3.17 Besu에서 트랜잭션 라이프사이클

 

 

5. 네트워크와 상호작용

로컬의 혹은 원격 어플리케이션은 하나의 노드와 통신함으로써 네트워크와 상호작용할 수 있다. 이 커뮤니케이션은 다양한 프로토콜과 API를 통하여 이루어질 수 있다. HTTP를 통한 JSON-RPC,  WebSockets를 통한 JSON-RPC, HTTP를 통한 GraphQL이 그것이다.

 

JSON-RPC는 JSON을 사용하는 RPC의 표준이며, 비상태 통신을 하는데의 규칙과 형식을 정의한다. Besu는 2.0 버젼을 지원한다. RPC가 보통 그러하듯, 호출하는 사람은 메소드의 이름과, 인자들이 포함된 요청을 페이로드 형태로 붙여 넘긴다. 3.5에서 해당 페이로드에 대해 예시가 있다. 

 

# 3.5 JSON-RPC example payload
{
	"jsonrpc": "2.0",
	"method" : "eth_blockNumber",
	"params" : [],
	"id" : 1
}

우리는 각 쿼리가 JSON-RPC 프로토콜, 메소드 이름, 메소드에 필요한 인자, 식별자로 구성되어 있음을 확인할 수 있다. 이 식별자는 응답을 기다리는 노드를 알려주는 데에만 사용된다. 만약 식별자를 포함시키지 않는다면, 클라이언트는 응답을 돌려받을 수 없다. 명백하게 JSON-RPC는 메시지 전달 환경과는 독립적으로 동작한다. 따라서 WebSockets을 통한 상호작용도 같이 사용 가능하다.

 

기본값으로 꺼져있긴 하지만, 요청을 할 때, 노드의 설정 파일에 정의한다면 유저 이름/ 비밀번호 쌍, 혹은 JWT를 통한 인증이 가능하다. 

 

마지막으로 HTTP를 통한 GraphQL이 지원된다. GraphQL은 호출하는 사람이 데이터 구조에서 어떤 항목을 요청하고 결과를 필터링할 수 있는 쿼리 언어이다. 자연스럽게, 쿼리 언어는 장부를 쿼리하기 위해 설계됐다. 추가적으로 GraphQL은 트랜잭션을 생성하는 등 다른 기능을 호출하는데 사용될 수도 있다. 3.6의 예시가 남은 트랜잭션의 개수를 쿼리해오는 방법을 보여주고 있다.

 

# 3.6 GraphQL example payload
{
	"query": "{pending {transactionCount}}"
}

 

라이브러리와 어플리케이션

비록 HTTP 혹은 WebSocket 메시지로 노드와 직접 통신하는 것이 가능하지만, 라이브러리를 사용할 수도 있다. Besu가 이더리움 프로토콜의 대부분을 구현하기 때문에(서명되지 않은 트랜잭션을 전송하는 부분 제외), 이더리움 프로토콜을 통해 상호작용할 수 있는 모든 라이브러리 들은 Besu에 사용할 수 있다. 유명한 라이브러리는 Web3.js(JavaScript), Web3j(Java), Web3py(Python), Nethereum(.Net)이 있다. 라이브러리와 마찬가지로 이더리움 네트워크와 통신하던 어플리케이션들도, 커스텀 네트워크의 스펙을 만족한다면,  Besu에 적용될 수 있다. Truffle, Remix 는 스마트 컨트랙을 배포하고 테스트 하는데 유명한 도구들이다. Tenderly도 분석자료를 모으고, 스마트 컨트랙을 모니터링하는데에 사용할 수 있다. 추가적으로 Prometheus도 Besu 네트워크를 모니터링 하는데 사용할 수 있다. Grafana는 Prometheus로 모은 데이터를 시각화할 수 있다. 그림 3.18은 Besu 네트워크의 모니터링 정보를 보여주는 Grafana 대시보드이다. 명백한 이유들로, 데이터 프라이버시와 같은 Besu의 특징 기능들은, 이더리움 라이브러리를 활용하는 경우에는 사용이 불가능하다. Besu 고유의 기능을 사용하려면 섹션 6.2에 자세히 설명된 Web3.js-eeea59와 같이 EEA 확장 버전을 사용할 수 있다.

 

그림 3.18 Besu 네트워크를 위한 Grafana 대시보드

 

EthSigner를 통핸 트랜잭션 전송

이 전에, 트랜잭션은 노드가 아니라 계정에 의해 생성된다고 설명했다. 어플리케이션이나 사용자 등 actor가 이 트랜잭션을 생성하고, 이 것을 JSON-RPC 프로토콜을 사용해 직접이든 라이브러리를 통해서든 노드에 보낸다. 이 트랜잭션이 네트워크에서 합법으로 인정 받으려면, 이것은 반드시 계정의 개인 키를 이용해서 서명되어야 한다. Go Ethereum, Open Ethereum 같은 전통적인 이더리움 노드들은 내장된 지갑이 있어, 공개 키/개인 키 쌍을 보관했다. 추가적으로 이 이더리움 클라이언트들은 eth_sendTransaction의 endpoint를 지원해서, actor들이 서명되지 않은 트랜잭션을 보낼 수 있었다. 서명되지 않은 트랜잭션 요청을 수령하면, 노드는 지갑의 개인 키를 보고 서명하여 네트워크에 뿌렸다. 하지만 Besu는 내장 지갑과 eth_sendTransaction을 통한 무서명 트랜잭션을 모두 지원하지 않는다. 

 

Besu에 있는 actor들에게는 eth_sendTransaction 메소드가 (구현되지 않아)사용 불가하므로, eth_sendRawTransaction 메소드가 대신 제공된다. 이 함수 역시 이더리움 프로토콜의 한 부분이다. 이 메소드는 서명된 트랜잭션을 입력으로 받는다. 3.7의 예시가 eth_sendRawTransaction 메소드를 JSON-RPC로 호출하는 페이로드 예시를 보여준다.

 

# 3.7 sendRawTransaction example
{
	" jsonrpc ": "2.0 ",
	" method ": "eth_sendRawTransaction ",
	" params ": ["0 xf869018203e ... "],
	"id": 1
}

 

sendRawTransaction 메소드를 사용하는 것은 트랜잭션을 생성할 때는 모두가 개인 키를 가지고 서명해야 하므로 어플리케이션에게 너무 많은 부담을 지게하는 것일 수도 있다. 그러므로 Besu는 EthSigner라는 소프트웨어 컴포넌트를 사용할 수 있다. 기본적으로, EthSigner는 eth_sendTransaction 메소드를 구현하며, 노드 앞에 붙어 프록시 컴포넌트의 역할을 한다. EthSigner를 통해 actor는 개인 키에 대해 알고, 트랜잭션에 생성하는 것에 대한 부담 없이 eth_sendTransaction 메소드를 사용할 수 있다. EthSigner는 무서명 트랜잭션을 받으면, 그것에 서명하고 노드의 eth_sendRawTransaction으로 보낼 것이다. 공개 키/개인 키 쌍 역시 EthSigner 인스턴스의 파일 시스템에 로컬로 저장하거나, Hashicorp Vault에 저장하거나, Key Vault of Microsoft Azure에 저장할 수 있다. 그림 3.19는 노드에 트랜잭션을 보내는 과정을 설명한다.

 

그림 3.19 트랜잭션 전송 과정

 

 

6. 허가

Besu는 멤버가 아닌 사람들의 접근을 막는 다양한 방법을 제공해 네트워크를 private로 유지할 수 있다. 허가와 관련된 Besu의 기술을 알아보기 전에 잠깐 언급하자면, 바닐라(순수) 이더리움 클라이언트 역시 이더리움 프라이빗 네트워크의 개념을 가지고 있다. 이더리움 프라이빗 네트워크는 메인넷이 아닌 네트워크로 정의되어 있다. 기본적으로 어떤 사람이든 새로운 제네시스 블록을 생성할 수 있고, 많은 피어를 그 네트워크에 붙일 수 있다. 하지만 이것은 그저 메인넷과 접점이 없는 고립된 네트워크일 뿐이다. 이것은 보호나 보안을 제공하지 않는다. 이더리움 프라이빗 네트워크와는 다르게, Besu 네트워크는 보호와 보안을 다양한 허가 기술로 제공하는 것을 목표로 한다. 몇몇 허가 기술은 로컬 노드 레벨에서만 적용될 수 있고, 온체인 레벨에서 적용될 수도 있다.

 

로컬 : 사용자-기반 인증

노드는 JSON-RPC 메소드를 호출할 수 있는 사용자 리스트를 포함하고 있는 toml 파일을 특정할 수 있다. 각 사용자들에 대해 다음 항목들이 특정된다: 공개 키, 비밀번호의 해시, 허가의 목록. 여기서 허가의 목록은 사용자가 호출할 수 있는 JSON-RPC 메소드의 이름의 목록을 말한다. 3.8에 예시가 있다. 이 형태의 인증은 노드에만 로컬 레벨에서 정의되고, 해당 설정파일을 정의한 노드에만 적용된다. 

 

# 3.8 User-Based Authentication
[ Users . username1 ]
password = " $2a$10$l3GA7K8g6rJ /Yv. YFSygCuI9byngpEzxgWS9qEg5emYDZomQW7fGC "
permissions =[" net :*"," eth : blockNumber "]
privacyPublicKey =" U7ANiOOd5L9Z / dMxRFjdbhA1Qragw6fLuYgmgCvLoX4 ="

[ Users . username2 ]
password = " $2b$10$6sHt1J0MVUGIoNKvJiK33uaZzUwNmMmJlaVLkIwinkPiS1UBnAnF2 "
permissions =[" net : version "," admin :*"]
privacyPublicKey =" quhb1pQPGN1w8ZSZSyiIfncEAlVY /M/ rauSyQ5wVMRE ="

 

사용자 이름과 패스워드는 노드에 요청하여 로그인할 때 사용한다. 노드는 공개 키 와 개인 키를 RSA를 기반으로 생성하여, 사용자를 위한 JWT를 생성한다. 만약 해당 옵션이 켜졌다면, 요청 헤더 Authorization 항목에 유효한 JWT를 입력한 클라이언트만 노드의 기능을 호출할 수 있다. 이것에 대한 예시는 그림 3.20에 나와있다.

 

그림 3.20 JWT를 이용한 공개키/개인키 인증

 

로컬/네트워크 : 노드 허가 목록

앞에 두가지 허가 기술은 노드의 API를 호출할 수 있는 actor에 초점을 맞췄다. Besu 네트워크의 모든 노드들은 bootnode와 peer discovery를 이용해 연결한다는 것을 다시 기억해보자. 여기서, 우리는 타동성(A가 B에 연결되고, B가 C에 연결되면, A가 C에 연결됨)이 이 연결에 적용됨을 알 수 있다. 게다가 공격자가 허가형 네트워크를 운용하는 조직과 전혀 접촉 없이, bootnode의 주소를 발견하고 연결할 수도 있다. 이것을 제한하지 않는다면, 전체 네트워크가 새롭게 연결된 노드를 인식하고 그들의 데이터를 모두 공유할 것이다. Besu는 연결 가능한 노드 목록을 정의해 이것을 해결한다. 목록에 없는 노드들의 연결은 거절한다. 이 참가 제한은 EEA의 엔터프라이즈 이더리움 클라이언트 정의에서 connectionAllowed 함수로도 알려져있다.

 

노드 허가목록을 사용하기 위해서, 네트워크의 모든 노드들은 유니크한 공개키와 개인키를 가지고 있어야 한다. 다음, 노드의 enode가 노드의 허가목록에 적혀있어야 한다. enode는 "enode://nodePubKey@host:port" 형식의 URL이다. 각 노드는 유니크하게 네트워크의 노드를 식별할 수 있다. 이 허가목록은 로컬의 toml 파일에 정의할 수 있다. 

 

로컬/네트워크 : 계정 허가 목록