EOS 노드 운영자들과 함께, EOS 네트워크 재단은 2023년 9월 14일 목요일까지 지연된 트랜잭션(예정된 트랜잭션/Scheduled Transactions이라고도 함)을 비활성화하는 계획을 개발했습니다. 이 단계는 Leap 5.0.0 릴리스를 위한 EOS 네트워크의 안정성과 성능을 더욱 강화하기 위해 필요합니다. 노드 운영자 및 애플리케이션 개발자의 조치가 필요합니다.

조치가 필요합니다!

모든 노드 운영자는 다음 일정에 따라 모든 노드에 대해 지연된 트랜잭션을 비활성화해야 합니다:

• Jungle & Kylin Test Networks:
  • 2023년 8월 28일 월요일 이후
  • 늦어도 2023년 9월 1일 금요일까지
• EOS 네트워크:
  • 2023년 9월 8일 금요일 이후
  • 늦어도 2023년 9월 14일 목요일까지

모든 애플리케이션 개발자는 서비스 중단을 방지하기 위해 늦어도 2023년 9월 7일 목요일까지 애플리케이션에서 지연된 트랜잭션 종속성을 제거해야 합니다.

노드 운영자 및 애플리케이션 개발자를 위한 지침은 이 해당 게시글의 마지막에 포함되어 있습니다.

변경된 이유는 무엇입니까?

지연된 트랜잭션은 2019년 10월(v2.0.0rc1)부터 공식적으로 더 이상 사용되지 않습니다. 그 이후로 이로인한 문제가 여전히 계속되고 있습니다. 지연된 트랜잭션은 노드 실행, 기록 제공, 스마트 컨트랙트 동작 이해, 계정 복구에 과도한 복잡성을 추가합니다.

지연된 트랜잭션이 상황을 어떻게 복잡하게 만드는가요?

• 복잡한 노드(Complicated Nodes): 지연된 트랜잭션으로 인해 생태계, 특히 일반 트랜잭션과 대조될 때 다양한 방법으로 실패할 수 있습니다.
• 기록 복잡성(History Complexities): 지연된 트랜잭션은 다섯 가지 상태 중 하나에 속하는 것부터 오류 처리 트랜잭션과 결합될 가능성에 이르기까지 지속적으로 기록 추적을 복잡하게 만들었습니다.
• 계약 가정(Contract Assumptions): 개발자는 지연된 트랜잭션이 예상대로 실행될 것이라고 가정했습니다. 그러나 현실은 오류 처리기와 함께 이러한 트랜잭션이 체인의 안전성을 손상시키지 않으면서 실행이 보장되지 않는다는 것입니다.

이제와서 지연된 트랜잭션을 제거하는 이유는 무엇입니까?

Leap v5.0.0에는 즉각적인 최종성(Instant Finality)이라는 프로토콜 기능이 포함되어 있습니다. 이 프로토콜 기능이 활성화되면 되돌릴 수 없습니다. 즉각적인 최종성(Instant Finality)이 활성화된 네트워크에 참여하려는 노드는 Leap v5.0.0을 실행해야 합니다.

또한 Leap v5.0.0 ‘max-scheduled-transaction-time-per-block-ms’ 구성 옵션을 무시하여 nodeos 코드에서 지연된 트랜잭션을 비활성화합니다. 위와 함께, 이는 Leap v5.0.0이 BP에 배포된 후에 지연된 트랜잭션을 다시 활성화할 수 없음을 의미합니다.

Leap 5.0.0 릴리스 및 프로토콜 업그레이드 이전에 지연된 트랜잭션을 비활성화함으로써 커뮤니티는 예상치 못한 문제를 사전에 해결할 수 있습니다.

지침

노드 운영자: 지연된 트랜잭션 비활성화

지연된 트랜잭션을 비활성화하려면 모든 노드(특히 블록 생성 노드)의 config.ini 파일에서 `max-scheduled-transaction-time-per-block-ms`를 “0”으로 설정하십시오.

config.ini:

[code block: max-scheduled-transaction-time-per-block-ms = 0]

개발자: 지연된 트랜잭션 사용량 확인

개발자는 앱에서 생성된 트랜잭션의 `delay_sec`에 0이 아닌 값이 사용되는지 또는 앱 컨트랙트에서 호출이 발생하는지 확인하여 애플리케이션에서 지연된 트랜잭션의 사용을 확인할 수 있습니다:

• `eosio::transaction` 내의 `send` 멤버 함수
• `send_deferred`
• `cancel_deferred`

개발자: 지연된 트랜잭션의 대안

컨트랙트에서 지연된 트랜잭션을 사용하여 나중에 작업을 자동으로 트리거하는 경우, 해당 작업은 다른 수단을 통해 트리거해야 합니다. 가능한 대체 솔루션은 다음과 같습니다:

• 프런트엔드는 사용자를 대신하여 작업 실행의 필요성을 감지하고 사용자에게 작업을 트리거하는 트랜잭션에 서명하라는 메시지를 표시합니다.
• 실패하지 않도록 설계된 보류 중인 작업의 대기열을 설정하고 누구나 해당 대기열을 처리하기 위해 호출할 수 있는 작업을 추가하도록 컨트랙트를 설계합니다. 선택 사항으로 대기열을 처리하는 작업을 주기적으로 호출하는 서비스를 배포합니다.

기록(History)

이번 변경 내역을 자세히 알아보고 싶다면 도움이 되는 몇 가지 링크를 참조하시기 바랍니다:

• v2.0.0-rc1의 기존 사용 중단 노트: https://github.com/EOSIO/eos/issues/7597
• 기존 사용 중단 제안: https://github.com/EOSIO/spec-repo/blob/master/esr_deprecate_deferred.md
• 2023년 8월 9일 노드 운영자 원탁 토론: https://www.youtube.com/watch?v=HMwJjUFEbuE&t=2523s
• 2023년 8월 16일 노드 운영자 원탁 토론: https://www.youtube.com/watch?v=qtkTstHfNcI&t=156