공개 테스트: 이더리움의 개인정보 보호 및 확장성을 위한 솔루션

블록 체인 인간 삶의 많은 영역을 개선할 것을 약속하는 혁신적인 기술입니다. 실제 프로세스와 제품을 디지털 공간으로 전송하고, 금융 거래의 속도와 신뢰성을 보장하고, 비용을 절감하며, 분산 네트워크에서 스마트 계약을 사용하여 현대적인 DAPP 애플리케이션을 만들 수 있습니다.

블록체인의 많은 이점과 다양한 적용을 고려할 때, 이 유망한 기술이 아직 모든 산업에 적용되지 않았다는 사실이 놀랍게 보일 수 있습니다. 문제는 현대의 분산형 블록체인에는 확장성이 부족하다는 것입니다. 이더리움은 초당 약 20개의 트랜잭션을 처리하는데 이는 오늘날의 역동적인 비즈니스 요구를 충족시키기에는 충분하지 않습니다. 동시에 블록체인 기술을 사용하는 기업은 해킹 및 네트워크 장애로부터 보호 수준이 높기 때문에 이더리움을 포기하는 것을 주저합니다.

블록체인의 분산화, 보안 및 확장성을 보장하여 확장성 트릴레마를 해결하기 위해 개발팀 Opporty 스마트 계약과 Node.js 기반 프라이빗 네트워크로 구성된 보조 체인인 Plasma Cash를 만들었습니다. 이 체인은 자신의 상태를 루트 체인(Ethereum)으로 주기적으로 전송합니다.

플라즈마 캐시의 주요 프로세스

1. 사용자는 스마트 계약 기능 '예금'을 호출하여 플라즈마 캐시 토큰에 입금하려는 ETH 금액을 전달합니다. 스마트 계약 기능은 토큰을 생성하고 이에 대한 이벤트를 생성합니다.

2. 스마트 계약 이벤트에 가입한 플라즈마 캐시 노드는 예금 생성에 대한 이벤트를 수신하고 토큰 생성에 대한 트랜잭션을 풀에 추가합니다.

3. 주기적으로 특수 플라즈마 캐시 노드는 풀에서 모든 거래(최대 1만 개)를 가져와 블록을 형성하고 머클 트리와 그에 따른 해시를 계산합니다. 이 블록은 검증을 위해 다른 노드로 전송됩니다. 노드는 Merkle 해시가 유효한지, 거래가 유효한지(예: 토큰 보낸 사람이 소유자인지 여부) 확인합니다. 블록을 확인한 후 노드는 스마트 계약의 'submitBlock' 기능을 호출하여 블록 번호와 Merkle 해시를 엣지 체인에 저장합니다. 스마트 계약은 블록 추가에 성공했음을 나타내는 이벤트를 생성합니다. 트랜잭션이 풀에서 제거됩니다.

4. 블록 제출 이벤트를 수신한 노드는 블록에 추가된 트랜잭션을 적용하기 시작합니다.

5. 어느 시점에서 토큰의 소유자(또는 비소유자)가 플라즈마 캐시에서 토큰을 인출하기를 원합니다. 이를 위해 그는 `startExit` 함수를 호출하여 토큰의 마지막 2개 거래에 대한 정보를 전달하여 자신이 토큰 소유자임을 확인합니다. Merkle 해시를 사용하는 스마트 계약은 블록에 트랜잭션이 있는지 확인하고 XNUMX주 후에 출금을 위해 토큰을 보냅니다.

6. 토큰 출금 작업이 위반으로 발생한 경우(출금 절차가 시작된 후 토큰이 사용되었거나 출금 전에 이미 다른 사람의 토큰이었던 경우), 토큰 소유자는 XNUMX주 이내에 출금을 반박할 수 있습니다.

개인정보 보호는 두 가지 방법으로 달성됩니다.

1. 루트 체인은 하위 체인 내에서 생성되고 전달되는 트랜잭션에 대해 아무것도 모릅니다. 플라즈마 캐시에 ETH를 입금하고 인출한 사람에 대한 정보는 공개됩니다.

2. 하위 체인은 zk-SNARK를 사용한 익명 거래를 허용합니다.

기술 스택

• NodeJS
• Redis
• 에뜨 리움
• 토양

테스트

플라즈마 캐시를 개발하면서 시스템 속도를 테스트한 결과 다음과 같은 결과를 얻었습니다.

• 초당 최대 35개의 트랜잭션이 풀에 추가됩니다.
• 최대 1개의 트랜잭션을 블록에 저장할 수 있습니다.

테스트는 다음 3개 서버에서 수행되었습니다.

1. Intel Core i7-6700 쿼드 코어 Skylake 포함 NVMe SSD – 512GB, 64GB DDR4 RAM
3개의 검증 플라즈마 캐시 노드가 생성되었습니다.

2. AMD Ryzen 7 1700X 옥타 코어 “Summit Ridge”(Zen), SATA SSD – 500GB, 64GB DDR4 RAM
Ropsten 테스트넷 ETH 노드가 상승했습니다.
3개의 검증 플라즈마 캐시 노드가 생성되었습니다.

3. Intel Core i9-9900K Octa-Core 포함. NVMe SSD – 1TB, 64GB DDR4 RAM
플라즈마 캐시 제출 노드 1개를 올렸습니다.
3개의 검증 플라즈마 캐시 노드가 생성되었습니다.
플라즈마 캐시 네트워크에 거래를 추가하기 위한 테스트가 시작되었습니다.

총계 : 개인 네트워크에 10개의 플라즈마 캐시 노드가 있습니다.

테스트 1

블록당 거래 한도는 1만 개입니다. 따라서 1만 개의 트랜잭션이 2개의 블록으로 분류됩니다(시스템이 트랜잭션의 일부를 관리하고 트랜잭션이 전송되는 동안 제출하기 때문에).

초기 상태: 마지막 블록 #7; 1백만 개의 거래와 토큰이 데이터베이스에 저장됩니다.

00:00 — 트랜잭션 생성 스크립트 시작
01:37 - 1만 건의 트랜잭션이 생성되고 노드로 전송이 시작되었습니다.
01:46 — 제출 노드는 풀에서 240개의 트랜잭션을 가져와 블록 #8을 형성합니다. 또한 320초 안에 10개의 트랜잭션이 풀에 추가되는 것을 볼 수 있습니다.
01:58 — 블록 #8이 서명되고 검증을 위해 전송됩니다.
02:03 — 블록 #8이 검증되고 스마트 계약의 'submitBlock' 기능이 Merkle 해시 및 블록 번호로 호출됩니다.
02:10 — 데모 스크립트 작업이 완료되어 1초 만에 32만 건의 거래가 전송되었습니다.
02:33 - 노드는 블록 #8이 루트 체인에 추가되었다는 정보를 수신하기 시작했으며 240개의 트랜잭션을 수행하기 시작했습니다.
02:40 - 이미 블록 #240에 있는 8개의 트랜잭션이 풀에서 제거되었습니다.
02:56 — 제출 노드는 풀에서 나머지 760개의 트랜잭션을 가져와 Merkle 해시 계산 및 서명 블록 #9를 시작했습니다.
03:20 - 모든 노드에는 1만 개의 240개 트랜잭션과 토큰이 포함되어 있습니다.
03:35 — 블록 #9가 서명되어 검증을 위해 다른 노드로 전송됩니다.
03:41 - 네트워크 오류가 발생했습니다.
04:40 — 블록 #9 검증 대기 시간이 초과되었습니다.
04:54 — 제출 노드는 풀에서 나머지 760개의 트랜잭션을 가져와 Merkle 해시 계산 및 서명 블록 #9를 시작했습니다.
05:32 — 블록 #9가 서명되어 검증을 위해 다른 노드로 전송됩니다.
05:53 — 블록 #9가 검증되어 루트 체인으로 전송됩니다.
06:17 - 노드는 블록 #9가 루트 체인에 추가되었다는 정보를 수신하기 시작했으며 760건의 트랜잭션을 수행하기 시작했습니다.
06:47 — 풀에서 블록 #9에 있는 트랜잭션이 지워졌습니다.
09:06 - 모든 노드에는 2백만 개의 트랜잭션과 토큰이 포함되어 있습니다.

테스트 2

블록당 350개의 제한이 있습니다. 결과적으로 3개의 블록이 생겼습니다.

초기 상태: 마지막 블록 #9; 2백만 개의 거래와 토큰이 데이터베이스에 저장됩니다.

00:00 — 트랜잭션 생성 스크립트가 이미 시작되었습니다.
00:44 - 1만 건의 트랜잭션이 생성되고 노드로 전송이 시작되었습니다.
00:56 — 제출 노드는 풀에서 320개의 트랜잭션을 가져와 블록 #10을 형성합니다. 또한 320초 안에 10개의 트랜잭션이 풀에 추가되는 것을 볼 수 있습니다.
01:12 — 블록 #10이 서명되어 검증을 위해 다른 노드로 전송됩니다.
01:18 — 데모 스크립트 작업이 완료되어 1초 만에 34만 건의 거래가 전송되었습니다.
01:20 — 블록 #10이 검증되어 루트 체인으로 전송됩니다.
01:51 - 모든 노드는 루트 체인으로부터 블록 #10이 추가되었다는 정보를 수신하고 320개의 트랜잭션을 적용하기 시작합니다.
02:01 - 블록 #320에 추가된 10개의 트랜잭션에 대한 풀이 지워졌습니다.
02:15 — 제출 노드가 풀에서 350개의 트랜잭션을 가져와 블록 #11을 형성했습니다.
02:34 — 블록 #11이 서명되어 검증을 위해 다른 노드로 전송됩니다.
02:51 — 블록 #11이 검증되어 루트 체인으로 전송됩니다.
02:55 — 마지막 노드가 블록 #10에서 트랜잭션을 완료했습니다.
10:59 — 블록 #9 제출에 대한 트랜잭션은 루트 체인에서 매우 오랜 시간이 걸렸지만 완료되었으며 모든 노드가 이에 대한 정보를 받고 350개의 트랜잭션을 수행하기 시작했습니다.
11:05 - 블록 #320에 추가된 11개의 트랜잭션에 대한 풀이 지워졌습니다.
12:10 - 모든 노드에는 1백만 개의 670개 트랜잭션과 토큰이 포함되어 있습니다.
12:17 — 제출 노드가 풀에서 330개의 트랜잭션을 가져와 블록 #12를 형성했습니다.
12:32 — 블록 #12이 서명되어 검증을 위해 다른 노드로 전송됩니다.
12:39 — 블록 #12이 검증되어 루트 체인으로 전송됩니다.
13:44 - 모든 노드는 루트 체인으로부터 블록 #12가 추가되었다는 정보를 수신하고 330개의 트랜잭션을 적용하기 시작합니다.
14:50 - 모든 노드에는 2백만 개의 트랜잭션과 토큰이 포함되어 있습니다.

테스트 3

첫 번째와 두 번째 서버에서는 하나의 검증 노드가 제출 노드로 대체되었습니다.

초기 상태: 마지막 블록 #84; 데이터베이스에 저장된 트랜잭션 및 토큰 0개

00:00 — 각각 3만 건의 거래를 생성하고 보내는 1개의 스크립트가 시작되었습니다.
01:38 — 1백만 개의 트랜잭션이 생성되었으며 제출 노드 #3으로 전송이 시작되었습니다.
01:50 — 제출 노드 #3이 풀에서 330개의 트랜잭션을 가져와 블록 #85(f21)를 형성했습니다. 또한 350초 만에 10개의 트랜잭션이 풀에 추가되는 것을 볼 수 있습니다.
01:53 — 1백만 개의 트랜잭션이 생성되었으며 제출 노드 #1으로 전송이 시작되었습니다.
01:50 — 제출 노드 #3이 풀에서 330개의 트랜잭션을 가져와 블록 #85(f21)를 형성했습니다. 또한 350초 만에 10개의 트랜잭션이 풀에 추가되는 것을 볼 수 있습니다.
02:01 — 제출 노드 #1이 풀에서 250개의 트랜잭션을 가져와 블록 #85를 형성했습니다(65e)
02:06 — 블록 #85(f21)가 서명되어 검증을 위해 다른 노드로 전송됩니다.
02:08 — 3초 안에 1만 건의 트랜잭션을 전송한 서버 #30의 데모 스크립트가 작업을 완료했습니다.
02:14 — 블록 #85(f21)가 검증되어 루트 체인으로 전송됩니다.
02:19 — 블록 #85(65e)가 서명되어 검증을 위해 다른 노드로 전송됩니다.
02:22 — 1백만 개의 트랜잭션이 생성되었으며 제출 노드 #2으로 전송이 시작되었습니다.
02:27 — 블록 #85(65e)가 검증되어 루트 체인으로 전송되었습니다.
02:29 — 제출 노드 #2는 풀에서 111855개의 트랜잭션을 가져와 블록 #85(256)를 형성했습니다.
02:36 — 블록 #85(256)가 서명되어 검증을 위해 다른 노드로 전송됩니다.
02:36 — 1초 안에 1만 건의 트랜잭션을 전송한 서버 #42.5의 데모 스크립트가 작업을 완료했습니다.
02:38 — 블록 #85(256)가 검증되어 루트 체인으로 전송됩니다.
03:08 — 서버 #2 스크립트 작업이 완료되어 1초 만에 47만 건의 트랜잭션이 전송되었습니다.
03:38 - 모든 노드는 루트체인으로부터 블록 #85(f21), #86(65e), #87(256)이 추가되었다는 정보를 받아 330k, 250k, 111855 트랜잭션을 적용하기 시작했습니다.
03:49 - 블록 #330(f250), #111855(85e), #21(86)에 추가된 65k, 87k, 256개의 트랜잭션에서 풀이 지워졌습니다.
03:59 — 제출 노드 #1은 풀에서 888145개의 트랜잭션을 가져와 블록 #88(214)을 형성하고, 제출 노드 #2는 풀에서 750개의 트랜잭션을 가져와 블록 #88(50a)을 형성했으며, 제출 노드 #3은 풀에서 670개의 트랜잭션을 가져왔습니다. 풀 및 양식 블록 #88(d3b)
04:44 — 블록 #88(d3b)이 서명되어 검증을 위해 다른 노드로 전송됩니다.
04:58 — 블록 #88(214)가 서명되어 검증을 위해 다른 노드로 전송됩니다.
05:11 — 블록 #88(50a)이 서명되어 검증을 위해 다른 노드로 전송됩니다.
05:11 — 블록 #85(d3b)가 검증되어 루트 체인으로 전송됩니다.
05:36 — 블록 #85(214)가 검증되어 루트 체인으로 전송됩니다.
05:43 - 모든 노드는 루트 체인으로부터 블록 #88(d3b), #89(214)이 추가되었다는 정보를 수신하고 670k, 750k 트랜잭션을 적용하기 시작합니다.
06:50 — 통신 실패로 인해 블록 #85(50a)가 검증되지 않았습니다.
06:55 — 제출 노드 #2는 풀에서 888145개의 트랜잭션을 가져와 블록 #90(50a)을 형성했습니다.
08:14 — 블록 #90(50a)이 서명되어 검증을 위해 다른 노드로 전송됩니다.
09:04 — 블록 #90(50a)이 검증되어 루트 체인으로 전송됩니다.
11:23 - 모든 노드는 블록 #90(50a)이 추가된 루트 체인으로부터 정보를 수신하고 888145개의 트랜잭션을 적용하기 시작합니다. 동시에 서버 #3은 이미 블록 #88(d3b), #89(214)의 트랜잭션을 적용했습니다.
12:11 - 모든 풀이 비어 있음
13:41 — 서버 #3의 모든 노드에는 3만 개의 트랜잭션과 토큰이 포함되어 있습니다.
14:35 — 서버 #1의 모든 노드에는 3만 개의 트랜잭션과 토큰이 포함되어 있습니다.
19:24 — 서버 #2의 모든 노드에는 3만 개의 트랜잭션과 토큰이 포함되어 있습니다.

장애물

플라즈마 캐시를 개발하는 동안 우리는 다음과 같은 문제에 직면했으며, 이를 점차 해결하고 해결 중입니다.

1. 다양한 시스템 기능의 상호 작용에 충돌이 발생합니다. 예를 들어, 풀에 트랜잭션을 추가하는 기능이 블록 제출 및 검증 작업을 차단했고, 그 반대의 경우도 마찬가지였기 때문에 속도가 저하되었습니다.

2. 데이터 전송 비용을 최소화하면서 엄청난 수의 트랜잭션을 보내는 방법은 즉시 명확하지 않았습니다.

3. 높은 결과를 얻기 위해 데이터를 어디에 어떻게 저장해야 하는지 명확하지 않았습니다.

4. 1만 건의 트랜잭션을 처리하는 블록의 크기가 약 100MB를 차지하기 때문에 노드 간 네트워크를 어떻게 구성할지 명확하지 않았습니다.

5. 단일 스레드 모드에서 작업하면 긴 계산이 발생할 때(예: Merkle 트리 구축 및 해당 해시 계산) 노드 간의 연결이 끊어집니다.

우리는 이 모든 것을 어떻게 처리했습니까?

플라즈마 캐시 노드의 첫 번째 버전은 트랜잭션 수락, 블록 제출 및 검증, 데이터 액세스를 위한 API 제공 등 모든 작업을 동시에 수행할 수 있는 일종의 결합이었습니다. NodeJS는 기본적으로 단일 스레드이므로 무거운 Merkle 트리 계산 기능으로 인해 트랜잭션 추가 기능이 차단되었습니다. 이 문제를 해결하기 위한 두 가지 옵션을 살펴보았습니다.

1. 각각 특정 기능을 수행하는 여러 NodeJS 프로세스를 시작합니다.

2. Worker_threads를 사용하고 코드 일부 실행을 스레드로 이동합니다.

결과적으로 우리는 두 옵션을 동시에 사용했습니다. 논리적으로 하나의 노드를 개별적으로 작동할 수 있는 3개의 부분으로 나누었지만 동시에 동기적으로

1. 풀에 트랜잭션을 받아들이고 블록을 생성하는 제출 노드입니다.

2. 노드의 유효성을 검사하는 검증 노드입니다.

3. API 노드 - 데이터 액세스를 위한 API를 제공합니다.

이 경우 cli를 사용하여 Unix 소켓을 통해 각 노드에 연결할 수 있습니다.

머클 트리 계산과 같은 무거운 작업을 별도의 스레드로 옮겼습니다.

이로써 모든 플라즈마 캐시 기능이 동시에 장애 없이 정상 작동하는 것을 달성했습니다.

시스템이 작동하자 우리는 속도 테스트를 시작했지만 불행하게도 초당 5건의 트랜잭션과 블록당 최대 000건의 트랜잭션이라는 만족스럽지 못한 결과를 받았습니다. 무엇이 잘못 구현되었는지 알아내야 했습니다.

우선, 시스템의 최대 성능을 파악하기 위해 플라즈마 캐시와의 통신 메커니즘을 테스트하기 시작했습니다. 우리는 이전에 Plasma Cash 노드가 유닉스 소켓 인터페이스를 제공한다고 썼습니다. 처음에는 텍스트 기반이었습니다. JSON 객체는 `JSON.parse()` 및 `JSON.stringify()`를 사용하여 전송되었습니다.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

우리는 이러한 객체의 전송 속도를 측정한 결과 초당 ~ 130k를 발견했습니다. json 작업을 위한 표준 함수를 교체하려고 시도했지만 성능이 향상되지 않았습니다. V8 엔진은 이러한 작업에 최적화되어 있어야 합니다.

클래스를 통해 트랜잭션, 토큰, 블록을 다루었습니다. 이러한 클래스를 만들 때 성능이 2배나 떨어졌는데, 이는 OOP가 우리에게 적합하지 않음을 나타냅니다. 나는 순전히 기능적인 접근 방식으로 모든 것을 다시 작성해야 했습니다.

데이터베이스에 녹음

처음에 Redis는 키-값 저장소, 해시 테이블 작업, 세트 등 우리의 요구 사항을 충족하는 가장 생산적인 솔루션 중 하나로 데이터 저장소로 선택되었습니다. 우리는 redis-benchmark를 시작했고 80개의 파이프라이닝 모드에서 초당 최대 1개의 작업을 수행했습니다.

고성능을 위해 Redis를 더욱 세밀하게 조정했습니다.

• Unix 소켓 연결이 설정되었습니다.
• 상태를 디스크에 저장하는 기능을 비활성화했습니다. 안정성을 위해 복제본을 설정하고 별도의 Redis에서 디스크에 저장할 수 있습니다.

Redis에서 풀은 하나의 쿼리로 모든 트랜잭션을 검색하고 트랜잭션을 하나씩 삭제할 수 있어야 하기 때문에 해시 테이블입니다. 일반 목록을 사용해 보았으나 전체 목록을 언로드할 때 속도가 느려졌습니다.

표준 NodeJS를 사용할 때 Redis 라이브러리는 초당 18개의 트랜잭션 성능을 달성했습니다. 속도가 9배나 떨어졌습니다.

벤치마크 결과 가능성이 확실히 5배 더 크다는 것을 보여주었기 때문에 우리는 최적화를 시작했습니다. 라이브러리를 ioredis로 변경했고 초당 25k의 성능을 얻었습니다. `hset` 명령을 사용하여 트랜잭션을 하나씩 추가했습니다. 그래서 우리는 Redis에서 많은 쿼리를 생성하고 있었습니다. 트랜잭션을 일괄 처리로 결합하고 `hmset` 명령 하나로 전송하는 아이디어가 탄생했습니다. 결과는 초당 32k입니다.

아래에 설명할 여러 가지 이유로 우리는 `Buffer`를 사용하여 데이터를 작업하고, 알고 보니 쓰기 전에 이를 텍스트(`buffer.toString('hex')`)로 변환하면 추가 정보를 얻을 수 있습니다. 성능. 따라서 속도는 초당 35k로 증가했습니다. 현재로서는 추가 최적화를 중단하기로 결정했습니다.

다음과 같은 이유로 바이너리 프로토콜로 전환해야 했습니다.

1. 시스템은 해시, 서명 등을 계산하는 경우가 많으며 이를 위해서는 '버퍼'에 데이터가 필요합니다.

2. 서비스 간에 전송될 때 이진 데이터의 무게는 텍스트보다 가볍습니다. 예를 들어, 1만 건의 트랜잭션이 포함된 블록을 보낼 때 텍스트의 데이터는 300MB 이상을 차지할 수 있습니다.

3. 끊임없이 데이터를 변환하면 성능에 영향을 미칩니다.

따라서 우리는 놀라운 '바이너리 데이터' 라이브러리를 기반으로 개발된 데이터 저장 및 전송을 위한 자체 바이너리 프로토콜을 기반으로 삼았습니다.

결과적으로 다음과 같은 데이터 구조를 얻었습니다.

-거래

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

— 토큰

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

-차단하다

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

일반적인 명령 `BD.encode(block, Protocol).slice();` 및 `BD.decode(buffer, Protocol)`을 사용하여 Redis에 저장하거나 다른 노드로 전달하고 검색하기 위해 데이터를 `Buffer`로 변환합니다. 데이터를 다시.

또한 서비스 간 데이터 전송을 위한 2개의 바이너리 프로토콜이 있습니다.

— Unix 소켓을 통한 플라즈마 노드와의 상호 작용을 위한 프로토콜

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

지역 :

• `유형` — 수행할 작업(예: 1) — sendTransaction, 2 — getTransaction;
• '페이로드' — 적절한 기능으로 전달되어야 하는 데이터
• `메시지 ID` — 응답을 식별할 수 있는 메시지 ID입니다.

— 노드 간 상호작용을 위한 프로토콜

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

지역 :

• '코드' — 메시지 코드(예: 6) — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
• `버전프로토콜` — 프로토콜 버전. 다른 버전의 노드가 네트워크에서 생성될 수 있고 다르게 작동할 수 있기 때문입니다.
• `시퀀스` - 메시지 식별자
• `countChunk` и `청크번호` 대용량 메시지를 분할하는 데 필요합니다.
• '길이' и '페이로드' 길이와 데이터 자체.

데이터를 미리 입력했기 때문에 최종 시스템은 Ethereum의 'rlp' 라이브러리보다 훨씬 빠릅니다. 불행하게도 우리는 앞으로 할 계획인 스마트 계약을 마무리하는 것이 필요하기 때문에 아직 이를 거부할 수 없었습니다.

우리가 속도에 도달했다면 35 000 초당 트랜잭션을 최적의 시간에 처리해야 합니다. 대략적인 블록 형성 시간은 30초 정도 소요되므로 블록에 포함시켜야 합니다. + 1 000 000 거래는 더 많이 보내는 것을 의미합니다. 100 MB의 데이터.

처음에는 `ethereumjs-devp2p` 라이브러리를 사용하여 노드 간 통신을 했지만 너무 많은 데이터를 처리할 수 없었습니다. 결과적으로 우리는 `ws` 라이브러리를 사용하고 웹소켓을 통해 바이너리 데이터를 전송하도록 구성했습니다. 물론 대용량 데이터 패킷을 보낼 때도 문제가 발생했는데, 덩어리로 나누어서 지금은 이런 문제가 사라졌습니다.

또한 Merkle 트리를 형성하고 해시를 계산합니다. + 1 000 000 거래에 필요한 사항 10 초 연속 계산. 이 시간 동안 모든 노드와의 연결이 끊어집니다. 이 계산을 별도의 스레드로 옮기기로 결정했습니다.

결론 :

사실, 우리의 연구 결과는 새로운 것이 아니지만, 어떤 이유에서인지 많은 전문가들은 개발할 때 이를 잊어버립니다.

• 객체 지향 프로그래밍 대신 함수형 프로그래밍을 사용하면 생산성이 향상됩니다.
• 모놀리스는 생산적인 NodeJS 시스템의 서비스 아키텍처보다 나쁩니다.
• 과도한 계산에 `worker_threads`를 사용하면 특히 i/o 작업을 처리할 때 시스템 응답성이 향상됩니다.
• 유닉스 소켓은 http 요청보다 더 안정적이고 빠릅니다.
• 네트워크를 통해 대용량 데이터를 신속하게 전송해야 하는 경우 웹소켓을 사용하여 바이너리 데이터를 청크로 나누어 전송하고, 도착하지 않으면 전달할 수 있는 다음 하나의 메시지로 결합하는 것이 좋습니다.

우리는 당신을 방문하도록 초대합니다 GitHub의 프로젝트: https://github.com/opporty-com/Plasma-Cash/tree/new-version

해당 기사는 공동 집필되었습니다. 알렉산더 나시반, 수석 개발자 클레버솔루션(주).

출처 : habr.com