EOSIO상의 손실 트랜잭션 완화

개요

EOSIO 생태계에서는 최근 협업과 개발의 부활이 목격되고 있습니다.

지난 몇 달 동안 전 세계 EOSIO 네트워크의 개발자와 노드 운영자들은 Mandel 네트워크 업그레이드를 위한 프로토콜 개선을 구축하기 위해 열심히 노력했습니다. 여기에는 주관적 청구(SB – Subjective Billing) 및 손실 트랜잭션에 대한 몇 가지 개선 사항이 포함됩니다.

지난 기사에서 우리는 노드가 실패한 트랜잭션을 제한할 수 있도록 하는 설정인 주관적인 청구를 살펴보았습니다. 우리는 그것의 역사를 설명하고 영향을 받는 사용자들 사이에 혼란과 좌절을 일으킬 수 있는 엣지 케이스를 탐구했습니다. 이 기사에서는 이러한 문제를 최소화하기 위해 네트워크 참여자가 할 수 있는 일에 대해 간략히 설명합니다.

주관적인 청구 이슈 경감

EOSIO 커뮤니티의 많은 구성원은 Mandel의 트랜잭션 수명 주기 개선을 기대하고 있지만 EOSIO 개발자와 운영자는 이미 SB의 가장 실망스러운 골칫거리 중 일부를 방지할 수 있는 좋은 위치에 있습니다.

현존하는 SB 기능에는 운영자가 일반 사용자의 SB를 줄이는 데 사용할 수 있는 여러 nodeos 옵션이 포함되어 있습니다. 한 옵션은 SB를 완전히 비활성화합니다. 다른 한 옵션은 특정 계정에 대하여 비활성화 하는 것입니다. 세 번째 옵션은 API 또는 P2P 엔드포인트에 대해서만 특별히 SB를 비활성화하는 것입니다. 이 세 번째 옵션은 버그가 존재하며, 운영자는 노드에 새로운 Mandel 3.1 바이너리를 구현할 때까지 이를 피해야 합니다.

다른 구성 옵션들은 체인 상태 저장 위치를 ​​수정하여 노드가 트랜잭션을 보다 효율적으로 처리하도록 도울 수 있습니다.

스마트 컨트랙트 개발자는 SB를 줄이기 위한 조치를 취할 수도 있습니다. 온체인 청구 또는 “객관적 청구”는 블록 탐색기를 통해 사용자에게 표시되지만 주관적 청구는 표시되지 않습니다. 감지할 수 없는 트랜잭션 실패를 방지하려면 SB를 피하는 것이 중요합니다. 개발자는 트랜잭션 실패로 이어질 조건을 감지하고 가능한 한 빨리 이를 거부하여 SB를 최소화할 수 있습니다. 혹은 대안적으로 실패한 트랜잭션에 대한 리소스 사용을 줄이기 위해 가능한 한 빨리 실패하도록 컨트랙트를 설계할 수 있습니다.

사용자도 주관적인 청구 문제를 피하기 위해 조치를 취할 수 있습니다. 추가 계정 CPU 리소스를 구입하거나, 제 3자 리소스 공급자를 사용하거나, 신뢰할 수 있는 API 앤드포인트에 연결하여 사용자는 트랜잭션 손실 가능성을 줄일 수 있습니다.

이러한 단계들을 함께 수행하면, Mandel의 채택이 사용자 경험을 최적화하기 위한 수정 사항과 강력한 새 도구들을 제공하기 전까지 주관적인 청구 및 거래 손실 문제를 완화하는 데 도움이 될 수 있습니다.

주관적인 청구 문제 및 손실 트랜잭션 해결을 위한 빠른 참조:

• 사용자는 추가 CPU 리소스를 구입하거나 외부 리소스 공급자를 사용하여 과도한 주관적 청구로 인해 트랜잭션이 거부될 가능성을 줄일 수 있습니다. API 엔드포인트를 신중하게 선택하면 트랜잭션이 과다 청구되는 것을 방지할 수도 있습니다.

• 노드 운영자는 실패한 트랜잭션을 너무 많이 보낼 가능성이 없는 계정을 결정할 수 있으며 다음을 사용하여 해당 계정들에 대한 주관적인 청구를 비활성화할 수 있습니다.

disable-subjective-account-billing = <accountname>

예를 들어 Greymass Fuel에 적용할 수 있습니다. 노드 운영자는 Greymass에 “신뢰할 수 있는(trusted)” 비율 제한 또는 Sybil 저항이 충분한지 여부를 결정할 수 있습니다. 운영자는 다음을 사용하여 Greymass Fuel에 대한 주관적 청구를 비활성화할 수 있습니다.

disable-subjective-account-billing = greymassfuel

• nodeos 2.x의 구현과 관련된 알려진 문제로 인해, disable_subjective_api_billing 및 disable_subjective_p2p_billing 선택적 매개변수를 사용하는 노드 운영자는 둘 다 true 또는 모두 false인 동일한 Boolean 값을 설정해야 합니다. 노드들은 그들의 노드를 Mandel 3.1로 업그레이드하여 이 버그를 수정할 수 있습니다.

• 또는 운영자가 disable-subjective-billing = true 옵션을 사용하여 주관적 청구를 완전히 끌 수 있습니다. 이 옵션은 이전에 언급한 disable-subjective-api-billing 및 disable-subjective-p2p-billing 옵션과 중복되기 때문에 향후 릴리스에서 더 이상 사용되지 않거나 권장되지 않으며 잠재적인 삭제로 표시될 수 있습니다.

• 노드 운영자, 특히 클라우드 노드에 있는 운영자는 nodeos 옵션(database-map-mode = heap 또는 database-map-mode = locked)을 사용하여 디스크 읽기 및 리소스 사용량을 줄일 수 있습니다. 또한 Linux 옵션인 tmpfs를 사용하여 체인 상태 디렉토리를 임시 파일 시스템으로 마운트하여 잠재적으로 트랜잭션 실행 속도를 높일 수 있습니다.

• 스마트 컨트랙트 개발자는 트랜잭션 실패를 유발하는 조건을 선제적으로 감지하고 가능한 한 빨리 이러한 트랜잭션을 거부할 수 있습니다. 이것은 주관적인 청구를 제거하는 것이 아니라 그 규모와 사용자에 대한 영향을 줄입니다.

• 또한 개발자는 컨트랙트를 구성하여 상당한 비용이 발생하기 전에 가장 가능성이 높은 실패가 조기에 발생하도록 할 수 있습니다.

심층 참조 – 세부 수정 사항

주관적인 청구 문제를 방지하기 위한 사용자 전략

노드 구성 조정은 주관적인 청구 문제를 해결하는 데 가장 효과적입니다. 그러나 사용자는 잠재적으로 이슈들이 발생할 가능성을 줄이는 몇 가지 사소한 변경을 수행할 수 있습니다.

사용자가 할 수 있는 첫 번째 작업은 추가 CPU 리소스를 구입하는 것입니다. 이 추가 CPU는 활성 블록 프로듀서에 대한 전파 경로에서 트랜잭션이 발생할 수 있는 모든 SB 잔액을 커버합니다. 사용자는 노드에서 SB 잔액을 볼 수 없으며 SB를 처리하기 위해 추가 리소스가 필요한지 여부를 알 수 없습니다. 추가 CPU를 보유하면, 어떠한 SB라도 노드가 네트워크를 통해 사용자의 트랜잭션을 전달하는 것을 방해하지 않도록 합니다.

또 다른 유용한 방법은 Greymass Fuel과 같은 리소스 공급자를 사용하는 것입니다. 이러한 도구는 리소스 관리의 부담을 사용자 경험과 분리합니다. 리소스 제공자는 트랜잭션의 첫 번째 서명자 역할을 하여 트랜잭션의 리소스 비용을 지불하고 사용자에게 수수료를 부과합니다. 이러한 도구의 인기로 인해 노드 운영자는 종종 이러한 계정에 대해 SB를 비활성화하여 사용자에게 SB 이슈를 피할 수 있는 쉬운 솔루션을 제공합니다.

더욱 숙련된 사용자는 선호하는 지갑의 옵션을 변경하여 안정적인 API 엔드포인트에 연결할 수 있습니다. 이러한 엔드포인트의 공식 리스트는 없습니다. 그렇지만, 사용자는 Aloha EOS의 블록 프로듀서 벤치마크 데이터에서 API 성능을 유추할 수 있습니다. 사용자는 이 도구를 사용하여 고성능 API 노드를 소유하고 있을 가능성이 있는 일관되게 실행 시간이 짧은 블록 프로듀서(BP)의 API 엔드포인트를 선택할 수 있습니다.

노드 운영자가 노드 구성을 개선하고, Mandel 3.1이 SB에 대한 개선 사항을 도입함에 따라 네트워크는 많은 이슈들을 완화할 수 있을 것입니다. 그 동안 이러한 전략들은 EOSIO 사용자의 경험을 개선하는 데 도움이 될 수 있습니다.

스마트 컨트랙트 개발자를 위한 주관적인 청구 고려 사항

스마트 컨트랙트 개발자는 특별한 개발 고려 사항들을 만들어 SB와 관련된 문제를 줄일 수 있습니다.

assert와 같은 기능이 전체 트랜잭션 실패를 유발하여 주관적인 청구가 발생할 수 있습니다. 실패 전에 이미 실행된 트랜잭션이 많을수록, 더 많은 SB가 트랜잭션의 첫 번째 서명 계정에 적용됩니다.

일반적인 실패 조건의 조기 감지를 구현하여 개발자는 실패한 트랜잭션을 더 일찍 종료하고 적용되는 SB를 줄일 수 있습니다.

또는 dApp은 잘못된 매개변수가 있는 트랜잭션을 보내는 것을 방지하기 위해 더 많은 사전 트랜잭션 검사를 통합할 수 있습니다.

개발자는 초기 서명 유효성 검사를 제외하고, 실패한 스마트 컨트랙트 기능은 주관적으로 청구된다는 점에 유의해야 합니다.

주관적인 과금은 거래의 서명 확인 단계 이후에 적용됩니다(자세한 내용은 A-1 참조). 이 때문에 스마트 컨트랙트 개발자는 액션 내의 기능 또는 트랜잭션 내의 액션을 재정렬하여 주관적인 청구를 줄일 수 있습니다.

예를 들어 스마트 컨트랙트의 보안 논직을 손상시키지 않는 한, 실패할 가능성이 더 높은 경우 트랜잭션 초기에 체크 기능을 배치할 수 있습니다. 이상적으로 이러한 함수는 많은 리소스를 사용하는 복잡한 계산 전에 가능한 한 빨리 평가되어야 합니다.

노드 운영자를 위한 구성 옵션

Nodeos는 EOSIO와 함께 제공되는 트랜잭션 벨리데이터 애플리케이션입니다. 노드 운영자는 이를 사용하여 체인상의 노드를 운영합니다. 여기에는 기능을 활성화, 비활성화 또는 조정하는 선택적 매개변수가 포함됩니다. 노드 운영자는 이러한 옵션들을 사용하여 서버 아키텍처에 맞게 nodeos를 최적화할 수 있습니다(A-3 참조).

특정 계정에 대한 주관적인 청구 비활성화

한 nodeos 옵션을 사용하면 노드가 개별 계정에 대한 주관적인 청구를 무시할 수 있습니다.

disable-subjective-account-billing = ACCTNAME

disable-subjective-account-billing 옵션은 이름이 ACCTNAME인 계정에 대해 SB를 끕니다. 노드 운영자는 이 옵션을 사용하여 리소스 과사용 위험이 낮을 것으로 예상되는 계정을 화이트리스트에 추가할 수 있습니다.

예를 들어, 노드 운영자가 Greymass Fuel이 거래 속도 제한 도구를 갖춘 신뢰할 수 있는 리소스 공급자라고 결정하면 다음 옵션을 활성화할 수 있습니다.

disable-subjective-account-billing = greymassfuel

이 옵션이 활성화되면 노드는 greymassfuel 계정에 대한 SB 도구를 비활성화합니다. 이 옵션은 Greymass Fuel이 주관적인 청구와 관련된 문제가 있는 계정들에 대한 대체 옵션을 제공할 수 있도록 합니다.

주관적 청구 비활성화

고성능 API 노드 또는 프라이빗 체인을 실행하는 것과 같은 일부 노드 운영자는 SB를 완전히 끌 수 있습니다. 두 세트의 구성 옵션이 약간 다른 동작으로 이를 수행합니다. 운영자는 향후 Mandel 업데이트에서 버그가 수정 될 때까지 두 번째 변형을 피해야 합니다.

변형 1:

disable-subjective-billing = <BOOLEAN> 

1(true)로 설정하면 disable-subjective-billing 매개변수가 해당 노드에 대해 SB를 완전히 끕니다. 운영자는 실패한 트랜잭션이 대역폭을 차지하지 않는 노드에서 이 옵션을 사용할 수 있습니다. 기본값은 true입니다.

변형 2:

disable_subjective_api_billing = <BOOLEAN>
혹은

disable_subjective_p2p_billing = <BOOLEAN>

disable_subjective_api_billing 및 disable_subjective_p2p_billing 옵션은 각각 노드의 API 엔드포인트 및 P2P 엔드포인트에 대한 SB를 개별적으로 해제하도록 설계되었습니다.

이러한 옵션들은 하나가 “true”이고 다른 하나가 “false”일 때 예기치 않은 동작이 나타날 수 있음을 인지하는 것이 중요합니다. Mandel 3.1은 이러한 문제들을 해결합니다.

버그 중 하나에서 SB가 비활성화된 엔드포인트는 계정의 기존 SB 잔액을 확인하지 않지만, 트랜잭션이 실패하면 엔드포인트는 여전히 SB를 추가합니다. P2P 엔드포인트와 API 엔드포인트는 동일한 주관적 과금 원장을 공유하므로, P2P 엔드포인트는 API 엔드포인트에서 적용된 모든 SB를 확인하고 그 반대의 경우도 마찬가지입니다. 이 공유 원장으로 인해 한 엔드포인트는 다른 엔드포인트가 의도하지 않게 SB에 청구한 계정의 트랜잭션을 거부할 수 있습니다.

이러한 옵션들과 관련된 다른 버그는 더 당혹스럽습니다. 이는 노드에 disable_subjective_api_billing이 true로 설정되고 disable-api-persisted-trx가 false로 설정된 경우에만 발생합니다.

disable_subjective_api_billing 옵션은 주관적인 청구를 무시하기 위한 것입니다. 대신 트랜잭션이 성공적인 경우, 노드는 다음 블록에서 계정의 SB를 확인합니다.

이러한 동작들 때문에 운영자들은 그들의 노드에 Mandel 3.1이 적용될 때까지 두 옵션을 동일한 값으로 설정해야 합니다. 운영자는 또한 disable-subjective-billing 옵션을 사용할 수 있지만 이는 오래된 관행이며 중복을 피하기 위해 더 이상 사용되지 않을 수 있습니다.

클라우드 노드 고려 사항

클라우드 노드를 사용하면 소규모 팀이 민첩하고 안정적으로 운영할 수 있습니다. 많은 노드 운영자는 가동 시간과 효율성을 위해 클라우드 기반 노드를 선호합니다. 그들은 높은 수준의 서버 운영을 전용 서비스에 맡김으로써 인터넷 최고의 회사와 동일한 보안 및 네트워킹의 이점을 누릴 수 있습니다. 그러나 최적이 아닌 구성을 사용하면 클라우드 노드에서 예기치 않은 트랜잭션 실패 및 주관적 또는 객관적인 초과 청구가 발생할 수 있습니다.

특히, 이러한 장애는 대부분의 클라우드 공급자가 부과하는 메모리 아키텍처 및 제한된 디스크 I/O 레인을 포함합니다. 이로 인해 서버의 RAM보다 느린 디스크 메모리에 액세스하는 트랜잭션에 대한 실행 시간 이슈들이 발생할 수 있습니다.

몇 가지 nodeos 옵션은 이로 인해 발생하는 성능 문제를 해결하는 데 도움이 될 수 있습니다.

옵션 1:

database-map-mode = heap 혹은 database-map-mode = locked

노드 운영자는 선택적 구성 매개변수 database-map-mode = heap 또는 database-map-mode = locked를 사용하여 디스크 I/O를 줄일 수 있습니다. 이러한 옵션들은 서버가 체인 상태를 저장하는 방식을 변경합니다.

heap 모드에서, 노드는 체인 상태를 스왑 가능한 메모리에 프리로드합니다. 상태는 우선적으로 RAM에 저장되며 물리적 RAM의 초과 실행은 온디스크 스왑 메모리로 푸시됩니다. 효과적인 노드 운영을 위해서는 스왑 성능만으로는 충분하지 않습니다. 그러나 물리적 RAM이 충분할 때 이 옵션을 사용하는 노드는 가장 자주 액세스된 데이터에 대한 데이터베이스 호출 속도를 높입니다. WAX 블록체인에서 테스트 결과 노드가 물리적 RAM에 저장된 상태의 절반 수준으로 효율적으로 작동할 수 있음을 발견했습니다.

locked 모드에서 노드는 스왑 메모리 없이 예약된 RAM 파티션에 전체 상태를 저장합니다. 이 옵션을 사용하려면 적어도 상태 크기만큼 큰 물리적 RAM이 필요합니다.

heap 및 locked 모드에는 최소량의 서버 RAM이 필요하므로, RAM이 제한된 노드는 이러한 옵션을 사용하지 않아야 합니다. Trust EVM 및 기타 EOS Network Foundation(ENF) 이니셔티브들의 출시가 임박함에 따라 이러한 운영자들은 사용량 증가를 수용하기 위해 리소스를 늘리는 것을 고려할 수 있습니다.

옵션 2:

tmpfs <DIRECTORY/TO/CHAIN/state>

노드는 Linux 명령 tmpfs를 사용하여 물리적 메모리와 스왑 메모리 간에 공유된 파티션 분할을 만들 수 있습니다. 운영자들은 이 tmpfs 파티션을 사용하여 체인 상태를 저장하고 스냅샷에서 이를 빌드할 수 있습니다(A-4 참조).

노드가 스냅샷에서 상태를 빌드하면, tmpfs 폴더는 매번 nodeos가 다시 시작될 때마다 상태를 다시 빌드할 필요를 제거합니다. 노드는 머신의 전원이 꺼지거나 tmpfs 폴더가 마운트 해제된 경우에만 상태를 재구축하면 됩니다.

tmpfs 폴더는 디스크 읽기 횟수를 줄일 수 있습니다. 디스크 읽기가 줄어들면 트랜잭션이 디스크에서 데이터를 수신하기 위해 대기 중인 사용 가능한 CPU 시간을 모두 사용할 가능성이 낮아집니다. 이 디스크 지연 시간은 트랜잭션 실패의 빈번한 원인입니다.

이러한 도구들은 노드 운영자가 주관적인 청구 문제를 방지하는 데 도움이 됩니다. Mandel의 채택은 많은 추가 기능 및 개선 사항들을 가져올 것입니다.

Mandel 개선사항

위의 단계들은 노드 운영자, 개발자 및 사용자가 거래 손실을 방지하는 데 도움이 되는 모범 사례들입니다.

EOSIO 핵심 네트워크 개발자들은 프로토콜 개선을 통해 이러한 단계가 덜 필요하게 될 것이라 예상하고 있습니다. EOSIO 소프트웨어의 다음 버전인 Mandel 3.1은 몇 가지 트랜잭션 수명 주기 개선 사항들을 구현할 것입니다. 다음 기사에서는 더 깊이 파고들지만 여기에서 네 가지 주요 기능 추가 및 업데이트를 간략하게 요약해보겠습니다.

• 트랜잭션 재시도(Transaction Retry)는 네트워크를 모니터링하고 최종 블록에 포함되지 않은 트랜잭션들을 자동으로 재시도합니다.
• 트랜잭션 리소스 비용 추정(Transaction Resource Cost Estimation)을 통해 지갑과 앱은 트랜잭션을 체인상에 적용하지 않고 리소스 사용량을 추정하기 위해 테스트 트랜잭션을 보낼 수 있습니다.
• 트랜잭션 최종성 상태(Transaction Finality Status)는 트랜잭션 풀로 들어오는 트랜잭션들을 추적합니다. 설정된 블록 수에 대해 최종성을 달성할 때까지 각 트랜잭션의 상태를 추적합니다.
• 주관적인 청구 개선 사항(Subjective Billing Improvements)은 SB 기능들을 다룹니다. 하나의 새로운 매개변수를 사용하여 SB 감쇠 시간을 조정할 수 있습니다. 다른 하나는 계정이 단일 블록 내에서 실패한 트랜잭션 허용량 이상을 전송한 경우 노드가 계정의 나머지 대기 트랜잭션들을 삭제할 수 있도록 합니다.

부록: 기술 세부 사항 및 사용 예시

A-1: 노드의 트랜잭션 처리 워크플로우

노드가 트랜잭션을 처리할 때 취하는 단계와 주관적인 청구 의미에 대한 자세한 설명은 다음과 같습니다.

계정은 처음에 스마트 컨트랙트 또는 리소스 제공자와 같은 한 명 이상의 공동 서명자와 잠재적으로 거래에 서명합니다(1).

트랜잭션이 노드에 도달하면 노드는 먼저 모든 트랜잭션 서명자들의 서명을 확인합니다(2).

서명 검증이 실패할 경우, 노드는 계정에 청구하지 않고 해당 트랜잭션을 삭제합니다(3).

서명 검증이 성공하면 트랜잭션은 (4)로 이동합니다.

다음으로, 노드는 계정의 남은 리소스 허용량을 계산합니다. SB가 비활성화된 노드는 SB(5)를 확인하거나 적용하지 않고 진행합니다.

SB가 활성화된 노드(6)는 트랜잭션의 첫 번째 서명자와 연결된 계정에 대해 SB 테이블(7)을 확인합니다.

계정에 주관적 청구서에 대한 리소스가 충분하지 않으면, 해당 트랜잭션은 청구되지 않고 취소됩니다(8).

계정에 리소스가 충분하면 트랜잭션이 다음 단계(9)로 진행됩니다.

다음으로, 노드는 트랜잭션(10)을 실행합니다. 트랜잭션을 실행하는 동안 사용하는 CPU 시간을 추적합니다.

트랜잭션의 일부가 실패하면, 노드는 트랜잭션을 삭제합니다. 계정에 트랜잭션 실패 전에 사용된 리소스에 대해 주관적으로 청구합니다(11).

트랜잭션이 성공적으로 실행되면(12) 다음 단계로 이동합니다.

다음으로 노드는 계산된 대로 계정의 SB 잔액을 리소스 청구에 추가합니다. 그런 다음 이를 계정의 사용 가능한 리소스와 비교합니다(13).

만약 계정에 리소스가 부족하면, 노드는 트랜잭션을 삭제하고 리소스 사용량에 대해 주관적으로 계정에 청구합니다(14).

만약 계정에 충분한 리소스가 있으면, 노드는 P2P 프로토콜을 통해 네트워크의 다른 노드들로 트랜잭션을 보냅니다(15).

또는 만약 해당 노드가 활성 블록 생산자인 경우, 트랜잭션 및 계산된 청구를 블록에 추가합니다(16).

A-2: 스마트 컨트랙트 개발자를 위한 고급 완화

스마트 컨트랙트 개발자를 위한 추가 고려 사항에는 트랜잭션 실패를 유발하는 assert() 및 check() 함수와 그렇지 않은 return 구문 사용이 포함됩니다. Return 구문들을 통해 주관적인 대신 청구 내용을 확인할 수 있도록 만들 수 있습니다. 그러나 사용자나 스마트 컨트랙트는 종종 잘못된 매개변수로 인해 트랜잭션 실패가 발생할 것으로 예상하고, Return 구문을 확인하는 데 신경 쓰지 않기 때문에 이 방법은 사용할 경우 신중해야 합니다. 그들은 return 구문이 성공 또는 실패를 보고했는지 확인하지 않고 성공적인 트랜잭션을 볼 수 있으며 트리거해서는 안되는 작업을 트리거할 수 있습니다.

이 관행은 다른 일반적인 스마트 컨트랙트 관행과 반대되므로 다른 SB 완화 기술들이 효과적이지 않은 상황에서만 사용해야 합니다.

삼진법(three-strikes rule) 및 주관적인 청구의 맥락에서 이 관행의 동기에 대해 자세히 알아보려면 해당 GitHub 이슈를 참고하시기 바랍니다.

A-3: API 노드 운영자를 위한 권장 구성 설정

이것은 API 노드에 대한 권장 구성 예시입니다. 운영자는 이러한 옵션을 nodeos config.ini 파일에 추가합니다. 다른 권장 구성 설정은 https://github.com/EOS-Nation/bpconfig/에서 해당 주제에 대한 EOS Nation의 주요 기사에서 찾을 수 있습니다.

wasm-runtime = eos-vm-jit

chain-state-db-size-mb = 32768

reversible-blocks-db-size-mb = 2048

http-max-response-time-ms = 300

read-mode = head

database-map-mode = heap

p2p-accept-transactions = false

disable-api-persisted-trx = true

http-validate-host = false

p2p-max-nodes-per-host = 2

agent-name = INSERT NAME OF OPERATOR HERE

max-clients = 0

net-threads = 5

http-threads = 8

verbose-http-errors = true

abi-serializer-max-time-ms = 2000

http-server-address = 0.0.0.0:8888

enable-account-queries = true

plugin = eosio::http_plugin

plugin = eosio::chain_api_plugin

tmpfs 사용 예 : 

A-4: tmpfs 사용 예

다음 예에서는 파일 시스템 테이블에 tmpfs 폴더를 생성하는 방법을 설명합니다. 이 폴더는 스냅샷에서 생성된 후 마운트되어 체인 상태를 저장하는 데 사용됩니다. 이 예는 WAX 블록체인에서 nodeos 인스턴스를 실행하는 것과 관련된 EOSphere의 기사에서 채택되었습니다. 여기에서 찾을 수 있습니다.

https://medium.com/eosphere/wax-technical-how-to-11-43695f583e89

tmpfs 파티션 생성 및 마운트

이 예에서는 zfs(“zettabyte file system”)를 사용하여 tmpfs 파티션을 생성합니다. 이 파티션은 Windows의 ntfs 또는 Apple의 apfs 파일 시스템과 같은 파일 시스템이지만 물리적 볼륨과 논리적 볼륨을 관리할 수 있는 기능이 있습니다. Zfs는 꼭 필요한 것은 아니지만 데이터 무결성과 성능을 향상시키기 위해 선호되는 경우가 많습니다. 파일 시스템 테이블 fstab의 값을 변경합니다.

> sudo nano /etc/fstab

tmpfs   <DIRECTORY/TO/state>  tmpfs rw,nodev,nosuid,size=129G,x-systemd.after=zfs-mount.service 0

> sudo mount -a

**마운트 되었는지 확인**

> df -h

Swap 파일 설정:

EOSphere 팀은 스왑 사이즈를 쉽게 조정하기 위해 파티션이 아닌 Swap 파일을 사용합니다. SSD를 사용하면 Swap 파일을 사용하는 데 문제가 발생하지 않습니다. 다음 예에서는 다음 기능들을 사용하여 Swap 파일을 128GB로 구성합니다.

***파티션일 가능성이 있는 기존 swap을 끕니다.***

> sudo swapoff -a

> sudo fallocate -l 128G /swap.img

> sudo chmod 600 /swap.img

> sudo mkswap /swap.img

> sudo swapon /swap.img

***fstab을 구성하고 이전 swap 구문을 주석 처리합니다.***

> sudo nano /etc/fstab

/swap.img   none    swap    sw    0   0

스냅샷에서 nodeos 시작하기

다음으로, 데이터베이스 사이즈를 설정하고 스냅샷을 nodeos에 로드합니다. nodeos 인스턴스는 가상 메모리에 스냅샷 상태를 저장하고 호스트 머신이 꺼지거나 tmpfs 파티션이 마운트 해제될 때마다 다시 빌드해야 합니다. ~/eosdata 필드는 사용자 정의된 임의의 이름이며 운영자가 사용자 정의 디렉토리 이름을 사용하는 경우 “/eosdata”의 모든 인스턴스가 사용자 정의 디렉토리 이름으로 대체되도록 해야 합니다.

시작하는 데 평소보다 더 오래 걸리며, 많은 스왑 저장소가 사용되는 경우 더 오래 걸립니다. 40GB RAM과 128GB 데이터베이스 크기, 81.4GB 메모리 활용의 경우, EOSphere는 재구축에 약 30분이 소요되는 것을 확인했습니다. nodeos  소프트웨어를 다시 시작하기 위해 상태를 다시 빌드할 필요가 없으며 머신이 다시 시작되거나 tmpfs가 마운트 해제될 때까지 사용할 수 있습니다.

***상태 데이터베이스 사이즈 구성***

> cd ~/eosdata

> nano config.ini

chain-state-db-size-mb = 131072

스냅샷을 다운로드하는 방법:

스냅샷은 https://snapshots.eosnation.io/와 같은 여러 위치에서 사용할 수 있습니다. 운영자는 스냅샷을 ~/eosdata/snapshots/snapshot.bin에 저장해야 합니다.

스냅샷에서 시작:

nodeos –data-dir ~/eosdata –config-dir ~/eosdata –snapshot ~/eosdata/snapshots/snapshot.bin