트론(TRX) 네트워크 업그레이드 세부 내용 소개

블록체인 체험기

by Happycoin 2022. 12. 13. 00:02

지난달 30일에 업비트 공지사항에 "트론(TRX) 네트워크 업그레이드에 따른 TRX, BTT, JST, SUN 입출금 일시 중단 안내"라는 제목이 보이더군요. 이번 업데이트를 통해 뭐가 변하는지 궁금하지 않을 수 없습니다.

오늘은 이번 트론 네트워크 업그레이드 내용은 무엇인지 살펴보도록 하겠습니다.

트론(TRX) 네트워크 업그레이드에 따른 TRX, BTT, JST, SUN 입출금 일시 중단 안내

아래사진은 지난달 30일 암호화폐 거래소 '업비트' 공지사항입니다.

화면 중간에 "TRX 네트워크 업그레이드 관련 내용 보기" 링크가 있는데 그것을 클릭하면 영문으로 된 업그레이드 세부 내용이 나옵니다.

TRX 네트워크 업그레이드 관련 세부 내용 링크는 아래와 같습니다.

https://coredevs.medium.com/greatvoyage-v4-6-0-socrates-release-note-c5b68423eff2

Introduction of GreatVoyage-v4.6.0 (Socrates)

The GreatVoyage-v4.6.0 (Socrates) introduces several important optimizations and updates, such as an optimized database checkpoint…

coredevs.medium.com

TRX 네트워크 업그레이드 관련 세부 내용 번역문

위 링크 언어는 영문입니다.

그래서 구글번역기와 파파고의 도움으로 한글로 번역했습니다.

GreatVoyage-v4.6.0 소개(소크라테스)

GreatVoyage-v4.6.0(Socrates)은 노드 운영의 안정성을 향상하는 최적화된 데이터베이스 체크포인트 메커니즘과 같은 몇 가지 중요한 최적화 및 업데이트를 도입합니다. 최적화된 리소스 위임 관계 인덱스 구조 및 트랜잭션 실행 속도를 높이고 네트워크 처리량을 증가시키는 업데이트된 투표 보상 알고리즘 TRON 네트워크의 보안과 신뢰성을 향상하기 위해 거래 메모 수수료를 추가하고 메모로 거래 비용을 증가시켜 소액 거래의 수를 줄이는 새로운 제안. 통합 툴킷, 새로운 네트워크 관련 Prometheus 메트릭 및 새로운 도움말 명령줄을 함께 사용하면 사용자에게 보다 편리한 개발 환경을 제공합니다.

자세한 사항은 아래를 확인해주세요.

핵심

1. 대리인 관계 색인 구조 최적화

TRON 네트워크에서 계정은 스테이킹을 통해 다른 계정에 리소스를 위임할 수 있으며 다른 계정이 자신을 위해 스테이킹한 리소스를 수락할 수도 있습니다. 따라서 각 계정은 계정이 리소스를 위임한 모든 수신자 주소와 계정에 대한 리소스를 위임한 모든 주소를 포함하여 위임 관계의 레코드를 유지 관리해야 합니다.

GreatVoyage-v4.6.0(Socrates) 이전 버전에서는 위임 관계가 목록 형식으로 저장됩니다. 자원 위임을 할 때 먼저 수신자 계정이 목록에 존재하는지 확인한 후 존재하지 않는 경우에만 목록에 계정을 추가해야 합니다. 특정 계정이 리소스를 여러 계정에 위임했거나 많은 계정이 리소스를 특정 계정에 위임한 경우 특정 계정에 대한 위임 관계 목록의 길이가 상당합니다. 조회 작업은 시간이 많이 걸리므로 트랜잭션 실행 시간이 길어집니다.

따라서 GreatVoyage-v4.6.0(Socrates)은 리소스 위임 관계의 인덱스 저장 구조를 최적화하고 목록에서 키-값 쌍으로 변경하여 일정한 시간 내에 데이터 쿼리 및 수정을 완료합니다. 위임 관련 트랜잭션의 실행 속도를 크게 높이고 네트워크 처리량을 향상합니다.

대리인 관계 스토리지 최적화는 TRON 네트워크의 동적 매개변수입니다. 기본적으로 비활성화되어 있으며 제안을 시작하여 활성화할 수 있습니다.

도움말: https://github.com/tronprotocol/tips/issues/476

소스 코드: https://github.com/tronprotocol/java-tron/pull/4788

2. 거래 메모 수수료 제안 추가

GreatVoyage-v4.6.0(Socrates)부터 메모가 있는 거래에 메모 수수료를 부과할 수 있습니다. 비용을 높임으로써 수수료는 TRON 네트워크의 보안과 신뢰성을 향상하기 위해 가치가 낮은 트랜잭션의 수를 줄입니다.

메모 수수료는 TRON 네트워크의 동적 매개변수입니다. GreatVoyage-v4.6.0(Socrates)이 배포된 후 기본값은 '0'이며 단위는 'sun'입니다. 제안을 시작하여 0이 아닌 값을 지정하여 활성화할 수 있습니다.

[아래 사진]은 티스토리 주인이 추가했습니다.

'note' 항목에 메모가 있음을 알 수 있습니다.

앞으로 이런 메모가 있는 것은 수수료를 부과할 수 있다는 내용입니다.

도움말: https://github.com/tronprotocol/tips/issues/387

소스 코드: https://github.com/tronprotocol/java-tron/pull/4758

3. 최적화된 보상 알고리즘 제안 추가

TRON 네트워크의 많은 유권자는 보상을 인출하기 전에 오랜 시간 동안 보상을 축적합니다. 두 번의 보상 인출 사이의 간격은 종종 매우 깁니다. GreatVoyage-v4.6.0(Socrates) 이전 버전에서는 보상을 출금하는 트랜잭션의 경우 마지막 보상 출금 이후 유지 기간마다 보상을 계산하여 누적하므로 마지막 보상 출금 이후 시간이 길수록 보상을 계산하는 데 더 많은 시간이 소요됩니다. 따라서 GreatVoyage-v4.6.0(Socrates)은 투표 보상 계산 알고리즘을 최적화합니다.

유지보수 기간마다 보상을 누적하는 대신, 미취 소 보상의 합계는 이전 유지 기간에 기록된 총보상에서 마지막 보상 철회의 유지 기간에 기록된 총 보상 수를 뺀 값으로 구할 수 있습니다. 이 알고리즘은 일정한 시간에 청구되지 않은 총 보상 수의 계산을 실현하여 계산 효율성을 크게 향상하고 보상 계산 실행 속도를 높여 네트워크 처리량을 향상합니다.

최적화된 보상 알고리즘은 TRON 네트워크 매개변수이며 GreatVoyage-v4.6.0(Socrates)이 배포되면 기본적으로 비활성화되며 제안을 통해 투표하여 활성화할 수 있습니다.

도움말: https://github.com/tronprotocol/tips/issues/465

소스 코드: https://github.com/tronprotocol/java-tron/pull/4694

4. 데이터베이스 모듈에서 체크포인트 메커니즘을 v2로 업그레이드

Checkpoint는 예외적인 종료로 인한 데이터베이스 손상을 방지하기 위해 설정된 복구 메커니즘입니다. Java-Tron은 데이터 저장을 위해 메모리 및 다중 디스크 데이터베이스를 사용합니다. 굳어진 블록의 데이터는 여러 비즈니스 데이터베이스에 저장됩니다. 미확인 데이터는 메모리에 저장됩니다. 블록이 굳어지면 해당 메모리 데이터가 관련 데이터베이스에 기록됩니다. 그러나 여러 비즈니스 데이터베이스에 쓰기 작업은 원자적 작업이 아니기 때문에 어떤 이유로 인해 예기치 않은 다운타임이 발생하면 블록의 모든 데이터를 디스크에 쓸 수 없으며 노드는 데이터베이스 손상으로 인해 다시 시작할 수 있습니다.

따라서 메모리 데이터가 디스크에 기록되기 전에 체크포인트가 생성됩니다. 체크포인트에는 이번에 각 비즈니스 데이터베이스에 작성해야 하는 모든 데이터가 포함되어 있습니다. 체크포인트가 생성된 후 먼저 체크포인트 데이터를 독립적인 체크포인트 데이터베이스에 쓴 다음 비즈니스 데이터베이스 쓰기 작업을 수행하며 체크포인트 데이터베이스는 항상 최신 굳은 블록 데이터를 유지합니다. 시스템 종료로 인해 비즈니스 데이터베이스가 손상된 경우 노드가 다시 시작된 후 이전에 체크포인트 데이터베이스에 저장된 데이터를 통해 비즈니스 데이터베이스를 복구합니다.

현재 Checkpoint 메커니즘은 대부분의 다운타임 상황을 처리할 수 있지만 다운타임으로 인해 비즈니스 데이터베이스가 손상될 가능성은 여전히 적습니다. 현재 LevelDB의 데이터 쓰기는 비동기식입니다. 프로그램은 LevelDB를 호출하여 디스크에 데이터 쓰기를 요청합니다. 실제로 데이터는 운영 체제의 캐시에만 기록되며 운영 체제는 자체 전략에 따라 실제로 디스크에 기록할 시기를 결정합니다. 노드가 Checkpoint 데이터베이스에 대한 쓰기를 막 끝내고 비즈니스 데이터베이스에 계속 쓰는 시점에 예기치 않은 다운타임이 발생하면 운영 체제에서 Checkpoint 데이터베이스에 쓴 데이터를 실제로 디스크에 쓰지 않았을 가능성이 있습니다. 이 경우 Checkpoint 데이터베이스에 복구 데이터가 없기 때문에 노드가 제대로 재시작되지 않습니다.

이 문제를 해결하기 위해 GreatVoyage-v4.6.0(Socrates)은 Checkpoint 구현을 V2 버전으로 업그레이드합니다. 체크포인트 메커니즘 V2는 여러 응고 블록 데이터를 저장합니다. 따라서 비정상 종료로 인해 최신 굳은 블록 데이터가 체크포인트 데이터베이스에 성공적으로 기록되지 않더라도 노드가 다시 시작될 때 과거의 굳어진 블록 데이터를 사용하여 비즈니스 데이터베이스를 복원할 수 있습니다.

체크포인트 메커니즘 V2는 구성 파일에서 기본적으로 비활성화되어 있습니다. 이 기능은 구성을 수정하여 활성화할 수 있습니다. 노드가 체크포인트 V2를 활성화하고 일정 시간 동안 실행된 경우 더 이상 V1으로 롤백할 수 없다는 점에 유의해야 합니다.

도움말: https://github.com/tronprotocol/tips/issues/461
소스 코드: https://github.com/tronprotocol/java-tron/pull/4614

5. 활성 노드와 백업 노드 간의 블록 생성 우선순위 최적화

슈퍼 대표가 활성 및 백업 노드를 배포하면 노드 간의 연결이 유지됩니다. 활성 노드와 백업 노드가 네트워크 문제로 인해 일시적으로 연결이 끊어지면 백업 노드는 활성 노드가 유효하지 않은 것으로 간주하고 블록 생성을 인계합니다. 활성 노드와 백업 노드가 동시에 블록을 생성하므로 중복 블록 생성 프로세스가 발생합니다. GreatVoyage-v4.6.0(Socrates) 이전 버전에서는 활성 노드와 백업 노드가 서로 생성된 동일한 높이 블록의 블록을 수신하면 둘 다 1–9 블록 생성 주기 동안 일시 중단됩니다. 즉, 슈퍼 대표는 1–9 블록을 놓칠 것입니다.

GreatVoyage-v4.6.0(Socrates)은 블록 생산 로직의 우선순위를 최적화합니다. 위의 상황이 발생하면 두 노드는 다른 노드가 생성한 블록의 해시 값을 비교합니다. 더 큰 블록 해시를 가진 노드는 계속해서 블록을 생성하고 더 작은 블록 해시를 가진 노드는 블록 생성 주기를 중단한 다음 계속해서 블록을 생성하고 블록 해시를 다시 비교합니다. 총 27명의 슈퍼 대표가 순차적으로 블록을 생성하기 때문에 블록 생성 주기를 건너뛰는 데 걸리는 시간은 81초입니다. 이 기간 동안 그들 사이의 연결 문제가 단기적인 네트워크 장애라면 복구할 수 있는 충분한 시간이 있습니다. 또한 이 두 블록을 받은 후 다른 노드도 해시가 큰 블록을 선택하고 해시가 작은 블록을 버립니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4630

6. 네트워크 모듈에 대한 Kademlia 알고리즘 최적화

Java-Tron 노드 ID는 노드가 시작될 때마다 재생성되는 임의의 숫자입니다. Java-Tron의 Kademlia 알고리즘 구현에서 노드 ID에 따라 노드의 거리를 계산한 다음 거리에 따라 노드 정보를 해당 K 버킷에 넣습니다. 어떤 이유로 K 버킷의 노드가 다시 시작되면 노드 ID가 변경됩니다. 노드가 다시 오프라인 상태임을 감지하면 최신 노드 ID에 따라 계산된 거리가 원래 K 버킷을 찾을 수 없으므로 버킷에서 노드를 삭제할 수 없습니다. 이러한 노드를 너무 많이 다시 시작하면 유효하지 않은 데이터가 노드의 K 버킷에 너무 많이 저장됩니다.

따라서 GreatVoyage-v4.6.0(Socrates)은 Kademlia 알고리즘을 최적화하고 해시 테이블을 사용하여 발견된 노드를 기록합니다. 노드의 거리는 처음 K 버킷에 쓰일 때 한 번만 계산되고 노드의 'distance' 필드에 할당된 후 노드가 해시 테이블에 추가됩니다. 앞으로는 이 필드를 통해 노드 거리를 직접 얻을 것입니다. 노드가 재시작된 후 노드 ID가 변경되더라도 Hash 테이블에 있는 노드의 거리는 업데이트되지 않습니다.

노드가 오프라인으로 감지되면 노드 IP에 따라 해시 테이블에서 해당 노드를 찾은 다음 노드 거리 필드를 통해 노드까지의 거리를 얻을 수 있으며 마지막으로 K 버킷에서 노드 정보를 삭제할 수 있습니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4620 https://github.com/tronprotocol/java-tron/pull/4622

기타 변경 사항

1. ArchiveManifest.jar을 Toolkit.jar에 병합

ArchiveManifest.jar는 독립적인 LevelDB 시작 최적화 도구로, LevelDB 매니페스트의 파일 크기를 최적화하여 메모리 사용량을 줄이고 노드 시작 속도를 크게 향상할 수 있습니다. GreatVoyage-v4.6.0(Socrates)부터 ArchiveManifest.jar 도구가 Toolkit.jar에 통합되었습니다. 앞으로 Java-Tron 주변의 모든 도구는 Toolkit.jar 도구 상자에 점진적으로 통합되어 도구 유지 관리 및 개발자 사용을 용이하게 할 것입니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4603

2. 네트워크 모듈에 대한 prometheus 메트릭 추가

GreatVoyage-v4.6.0(Socrates)은 네트워크 모듈과 관련된 세 가지 새로운 Prometheus 메트릭인 블록 가져오기 지연, 블록 수신 지연 및 메시지 처리 지연을 추가합니다. 새로운 지표는 노드의 네트워크 상태 모니터링에 도움이 됩니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4626

3. — help 명령 옵션 추가

GreatVoyage-v4.6.0(Socrates)은 모든 매개변수와 지침을 확인하기 위해 '도움말' 명령줄 옵션을 추가합니다. 아래 예시를 확인해주세요,

소스 코드: https://github.com/tronprotocol/java-tron/pull/4606

4. LiteFullNodeTool.jar 최적화

LiteFullNodeTool.jar는 Java-Tron의 라이트 노드 도구입니다. 주요 기능은 풀 노드 데이터베이스를 라이트 노드 데이터베이스로 변환하는 것입니다. GreatVoyage-v4.6.0(Socrates)은 도구를 최적화하고 도구의 편의성과 안정성을 향상합니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4607

5. eth_getBlockByHash 및 eth_getBlockByNumber API의 반환 값 최적화

Ethereum의 JsonRPC 2.0 프로토콜 인터페이스와 더 잘 호환되도록 GreatVoyage-v4.6.0(Socrates)은 eth_getBlockByHash 및 eth_getBlockByNumber API의 반환 값에서 `timestamp` 필드의 단위를 밀리초에서 초로 변경하여 반환 값을 이 두 API는 Ethereum Geth와 완벽하게 호환됩니다.

소스 코드: https://github.com/tronprotocol/java-tron/pull/4642

- 세상을 움직이려면 우리 자신을 움직여야 합니다. - - 소크라테스

번역문은 여기까지입니다.

전문 용어가 너무도 많아서 몇 번을 읽어도 이해가 잘 되지 않습니다. 앞으로 더 몇번 더 읽어봐야 이해가 될 것 같습니다.

위 본문에서 하늘색으로 표시된 부분에 따르면 앞으로 메모에 무슨 내용을 표시하면 전송 수수료가 붙을 수도 있을 것 같네요. 사실 트론 링크 지갑 사용하다 보면 메모에 긴 내용이 적힌 스팸이 꽤 귀찮게 오고 있거든요. 이번 업그레이드로 이런 스팸 전송이 줄어들었었으면 좋겠네요.

그런데 선의의 피해자는 없었으면 좋겠습니다.

저도 트론 전송 시에 가끔씩 메모에 관련 내용을 첨부하는 경우가 있거든요...

[아래 사진]은 최근 트론 지갑 업데이트 주요 내용입니다. 버전은 v3.26.15입니다.