Sui의 대규모 병렬 처리에는 네트워크에서 트랜잭션을 처리하는 데 드는 비용인 가스 수수료를 적용하는 방법에 대한 새로운 사고가 필요합니다. 저희는 최적의 가스비 메커니즘을 설계하기 위해 계산 비용과 명령어 처리를 조사합니다. 정확하게 평가된 가스 수수료는 공정한 네트워크 비용 분배와 건전한 운영 비즈니스 모델을 제공할 뿐만 아니라 개발자가 적절한 리소스 사용을 보장하기 위해 모범 사례를 사용하도록 장려합니다.

Sui의 가스 모델은 검증자 설문조사를 활용하여 가스 가격을 설정하고 온체인 트랜잭션의 비용이 네트워크 운영 비용에 따라 조정되도록 합니다. 그러나 Sui 트랜잭션의 특정 비용을 정의하는 것은 각 트랜잭션에 여러 지침이 포함되어 있고 네트워크가 여러 트랜잭션을 동시에 처리할 수 있다는 사실 때문에 복잡합니다. 다시 말해, 각 트랜잭션의 비용은 몇 가스 단위여야 할까요?

트랜잭션을 연속적으로만 처리할 수 있는 다른 블록체인과 같은 방식으로 트랜잭션당 가스 요금을 적용하면 Sui 사용자에게 과금이 부과될 가능성이 높습니다. 저희 모델은 네트워크 리소스 사용량을 보다 정확하게 표현하기 위해 명령어 수, 스택 깊이, 메모리 사용량을 측정하는 것을 포함합니다. 현재 진행 중인 작업에는 시뮬레이션 및 실제 테스트를 통해 시장 기반 가스 가격과 리소스 기반 가스 스케줄을 제공하여 Sui 사용자와 네트워크 상태에 맞는 효율적인 가스 요금 메커니즘을 제공하는 것이 포함됩니다.

요약하면, 다음과 같은 큰 단계를 거쳐 Sui 의 가스 요금 메커니즘을 개발했습니다:

• 리소스 사용량을 계산하는 가장 좋은 방법 결정하기
• 계산 비용을 계산하는 방법 설계
• 다양한 부하 가정을 기반으로 가스 요금 모델을 분석합니다.

병렬 처리 네트워크에서의 리소스 사용량 

블록체인은 공유 리소스이므로 가스비는 해당 리소스의 사용량을 고려하여 검증자에게 네트워크 유지에 필요한 운영 비용을 보상합니다. 또한 가스비는 사용자 행동에 영향을 미치므로 신중한 네트워크 사용을 장려하고 오용을 방지할 수 있습니다.

솔리디티와 이더리움 가상 머신과 같은 많은 블록체인 언어와 Move 의 특정 방언은 바이트코드 기반 계량 방식을 사용하여 특정 비용을 각 개별 바이트코드 명령어와 연관시킵니다. 이러한 설정에서 각 바이트코드 비용과 기본 계산 비용(즉, CPU 주기)의 정확도는 이러한 명령어 비용의 상대적 크기만큼 중요하지 않습니다. 예를 들어 Add 명령어의 런타임이 1밀리초이고 Div의 런타임이 2밀리초인 경우, 중요한 것은 gas_cost(Div)/gas_cost(Add) ~= 2인 반면, gas_cost(Add) 및 gas_cost(Div)에 할당된 실제 기본 숫자는 덜 중요합니다.

전체 주문이 프로토콜의 일부인 전통적인 블록체인에서는 단일 트랜잭션을 네트워크의 독점적 사용으로 간주하는 것이 합리적입니다. 특히 한 사용자가 어떤 연산을 실행하면 다른 사용자는 이전 연산이 완료될 때까지 자신의 연산을 실행할 수 없습니다. 이러한 설정에서 가스 비용은 트랜잭션 처리가 제로섬 게임이기 때문에 트랜잭션의 상대적인 런타임을 잘 반영해야 합니다. 즉, 내가 시간을 가졌으니 다른 사람들은 그렇지 않다는 것입니다.

"트랜잭션이 자체적으로 실행되는 것처럼 가격을 책정하는 것은 정확하지 않을 수 있으며, 실제로는 사용자에게 상당히 과다한 요금을 부과할 가능성이 높습니다."

그러나 Sui 에서는 프로토콜에 대규모 병렬 실행이 포함되어 있어 리소스를 배타적으로 사용하지 않습니다. 트랜잭션이 단독으로 실행되는 것처럼 가격을 책정하는 것은 정확하지 않을 수 있으며, 실제로는 사용자에게 상당히 과도한 요금을 부과할 가능성이 높습니다. 트랜잭션 처리는 더 이상 제로섬 게임이 아니며, 수천 또는 수십만 명이 동일한 시간을 공유하여 트랜잭션을 처리할 수 있습니다.

Sui의 병렬성으로 인해 저희는 한 걸음 물러나 실행 중 가스 계량에 대한 기존의 명령어 기반 접근 방식이 이 새로운 프로토콜에 가장 적합한지 검토하게 되었습니다. 특히 병렬 처리로 인해 리소스 사용 비용에 변동이 생기므로 명령어별 가격을 적용하는 대신 유사한 것들을 함께 그룹화하는 모델이 필요했습니다. 예를 들어, 두 정수를 더하는 데 드는 특정 비용과 두 정수를 나누는 데 드는 다른 특정 비용은 병렬 아티팩트로 인해 실제 런타임 비용을 예측하기가 더 어렵기 때문에 덜 중요해집니다.

이를 염두에 두고, 저희는 실행의 새로운 병렬 측면을 포착하고, 결과 모델을 최대한 이해하기 쉽고 합리적으로 만들며, 가장 중요한 것은 이러한 성과를 Sui 사용자에게 돌려줄 수 있는 가스 모델을 설계하기 시작했습니다. 이 모델을 개발하면서 각 계산 주기를 측정하려는 본질적으로 직렬적이고 기록적인 바이트코드 기반 가스 메커니즘을 적용하는 접근 방식을 거부하고 대신 실행을 위한 곡선 또는 계층 기반 가스 모델을 설계하게 되었습니다. 

Sui 의 가스 모델 설계

공정한 가스 요금으로 이어지는 정확한 계산 비용 모델을 마련하기 위해서는 거래 시간 측정과 같은 비교적 쉬운 방법을 버리고 다른 계산 요소를 조사해야 했습니다. 합리적인 모델에 도달하는 것과 함께 다음 사항도 고려해야 했습니다. Sui의 스토리지 수수료도 고려해야 했습니다.

컴퓨팅 비용

병렬 처리와 효율적인 계산이 기본으로 제공되는 Sui 에서 단일 명령어 실행의 비교 오버헤드는 전체 트랜잭션 실행 시간이나 기간에 덜 중요해집니다. 대신 정확한 오버헤드를 결정하는 데는 실행된 명령어의 수가 가장 중요합니다. 많은 수의 바이트코드 명령어를 실행한 후에야 각 명령어의 실제 런타임 비용 차이가 트랜잭션의 전체 런타임에 중요한 영향을 미치게 됩니다.

또한 연속 실행 시스템의 경우에도 실제 실행 비용을 정확하게 반영하는 비용 모델을 만들려면 여러 가지 과제를 극복해야 합니다. 

• 복잡하고 고도로 복잡한 가스 충전 메커니즘은 이해하고, 프로그래밍하고, 정확하게 구현하기가 어렵습니다. 
• 명령어에 대한 가스 계산은 실제 명령어 실행만큼이나 비용이 많이 들 수 있습니다. 
• 가스 모델의 복잡성에 관계없이 모델에서 고려되지 않은 다른 상황 정보(본질적으로 합리적으로 모델링하는 것이 불가능)에 따라 동일한 명령의 실행 시간이 크게 달라질 수 있습니다. 종이, Broken Metre: EVM의 리소스 미터링 공격에서 이러한 문제를 심도 있게 살펴볼 수 있습니다.

이러한 문제를 염두에 두고, 저희는 Sui 에서 가스 계산을 위한 더 나은 비용 모델이 있는지 알아보기 시작했습니다. 명령어와 메모리의 정밀하고 개별적인 계산에 의존하지 않고 다양한 차원의 계산을 통해 비용 모델을 거칠게 만드는 방법을 검토했습니다. 또한 결과 모델을 최대한 단순하고 이해하기 쉽게 만드는 동시에 사용자에게 공정하고 정확한 결과를 제공하는 것을 목표로 했습니다.

이러한 탐색을 통해 세 가지 요소를 기반으로 실행 중에 다양한 차원의 계산 비용을 동시에 추적하는 모델에 도달했습니다: 

• 인스트럭션 수
• 스택 깊이 
• 메모리 사용량 

이러한 각기 다른 비용은 서로 다른 가중치로 서로 다른 방식으로 트랜잭션 리소스 사용에 기여하며, 트랜잭션이 실행되는 동안 점점 더 많은 리소스가 사용됨에 따라 각 단위(예: 단일 명령어 실행, 단일 바이트 할당)를 사용하는 비용이 증가하게 됩니다. 각 리소스가 증가하는 양과 리소스가 증가하기 시작하기 위해 얼마나 많은 리소스를 사용해야 하는지는 서로 다른 비용 곡선을 사용하여 서로 독립적으로 정의됩니다. 그런 다음 실행 중 각 차원에 대한 각 비용을 단계 함수와 결합합니다.

이 새로운 모델의 핵심 아이디어는 사이클 단위로 정확한 정확도를 목표로 하는 것이 아니라 거래 비용이 비슷한 범위를 정의하는 것이었습니다. 또한 단일 명령의 개별 비용은 트랜잭션의 모든 명령을 실행하는 데 드는 전체 비용보다 덜 중요합니다. 따라서 이 새로운 디자인은 트랜잭션에서 리소스를 더 많이 사용할수록 해당 리소스의 비용이 더 많이 발생하는 리소스 비용에 대해 보다 동적인 관점을 취합니다. 저희는 이 논문에서 영감을 얻었습니다, 이더리움이 저가의 DoS 공격을 방어하기 위한 적응형 가스비 메커니즘에서 영감을 얻었습니다. Ting Chen, Xiaoqi Li, Ying Wang, Jiachi Chen, Zihao Li, Xiapu Luo, Man Ho Au, Xiaosong Zhang 연구원이 작성한 논문입니다.

이러한 방식으로 명령어와 리소스 사용량에 동적으로 가격을 책정하면 특정 범위 내에서 리소스 사용량을 과소 책정할 수 있습니다. 이러한 범위를 초과하면(예: 공격 시나리오에서) 실행 중에 이러한 리소스의 동적 가격 책정으로 인해 결국 계산이 너무 비싸져 합리적으로 악용할 수 없게 된다는 것을 알고 있기 때문입니다. 계산 사용량이 적은 경우(예: 명령어 10만 개 미만, 총 할당량 1메가바이트 미만)에는 리소스 사용량을 낮게 책정하는 기능을 통해 구현, 설명, 추론 모두에서 복잡성을 최소화하면서 '의식적인 계산'을 장려하고 장려할 수 있습니다.

"이 설계를 사용하면 가스 비용에 대한 코드 최적화의 필요성을 덜 수 있습니다."

계산 복잡성이 낮은 수준(모든 인스트럭션에 가스 단위가 하나, 모든 할당에 가스 단위가 하나)에서 모델이 단순하기 때문에 이 모델은 이해하기 쉽고 비용도 저렴합니다. 이 설계는 가스 비용에 대한 코드 최적화의 필요성을 줄여줍니다. 모든 인스트럭션 비용이 동일하기 때문에 최적화하는 것은 거의 불가능합니다. 

이러한 방식으로 저희는 가스 모델을 사용하여 적절한 프로그래밍 설계를 장려하고, 종종 프로그램에 해가 될 수 있는 사소한 세부 사항, 단일 바이트코드 명령, 모호한 최적화에 집중하지 않도록 합니다. 동시에 개발자가 자신의 계산과 사용하는 리소스를 인식하는 동시에 리소스 사용량을 공정하게 계산할 수 있기를 바랐습니다.

비컴퓨팅 비용

위에서 설명한 계산 비용 외에도 Sui 에서 거래를 실행하는 데 드는 전체 비용에 중요한 추가 비용이 있습니다. 현재 이 추가 비용의 두 가지 주요 원인은 장기 보관 비용과 가스 비용 반올림입니다. 

스토리지 비용은 다음과 같은 고유한 방식으로 처리됩니다. Sui의 스토리지 펀드. 트랜잭션 실행이 완료되면 장기 스토리지에 할당할 데이터를 계산하고 이 추가 비용이 트랜잭션 실행의 전체 비용에 추가됩니다. 또한 누군가가 스토리지를 삭제하면 스토리지 환불이 발생하여 트랜잭션의 총 비용을 줄이거나 환불을 받을 수도 있습니다. 그러나 이러한 유형의 스토리지 환불은 트랜잭션이 실행된 이후에만 평가되므로 트랜잭션을 실행하는 동안 사용할 수 있는 전체 가스 양에 영향을 줄 수 없습니다. 

가스 비용 반올림은 가스 계량에서 1,000에서 5,000,000 범위의 버킷에 계산 단위를 넣는 단계 기능으로 인해 발생합니다. 1,000 미만의 계산 단위를 사용하는 모든 거래는 1,000으로 반올림되므로 추가 비용이 무시할 수 있을 정도로 적습니다.

자세한 Sui 가스 비용 분석

우리가 설계한 가스 비용 모델은 이론뿐만 아니라 실제로도 작동해야 합니다. 이를 테스트하기 위해서는 다양한 가상 워크로드에 대한 트랜잭션 비용을 살펴봐야 했습니다. 특히, N개의 명령이 주어졌을 때 비용 모델에서 각 명령에 대한 할당 또는 푸시 앤 팝의 값이 다를 경우 비용은 어떻게 달라지는지 살펴보았습니다.

합성 사례 1: 할당이 없는 지침

먼저 가장 합성적인 워크로드, 즉 스택에 영향을 미치지 않는 할당이 없는 명령어부터 살펴보겠습니다. 각 명령은 본질적으로 NoP 명령입니다. 아래에서는 X축을 따라 점점 더 많은 명령어가 실행될 때 발생하는 실행 비용을 Y축에서 확인할 수 있습니다.

이 테스트에서 볼 수 있듯이, 그리고 앞서 설명한 것처럼 인스트럭션당 비용은 선형적이지 않습니다. 특정 임계값을 넘으면 요금에 상수가 곱해져 최종 비용이 더 비싸지게 됩니다. 목표는 가능한 한 오랫동안 비용을 억제하는 동시에 유사한 효과를 초래하는 서비스 거부 공격이나 네트워크 사용을 방지하는 것입니다.

이러한 비선형적인 비용 증가를 통해 대부분의 일반적인 네트워크 사용에 대한 비용을 억제하는 동시에, 사용자가 기꺼이 비용을 지불할 의사가 있는 경우 더 높은 수수료를 지불하고 대용량 트랜잭션을 실행할 수 있도록 합니다. 마지막으로, 리소스 사용이 더 이상 정당화되지 않고 시스템과 다른 사용자에게 불이익을 줄 가능성이 있는 시점이 있어야 합니다. 따라서 특정 사용과 리소스 소비에 대해서는 엄격한 상한선을 두지 않으면서도 비용을 엄청나게 비싸게 만들고자 합니다.

합성 사례 2: 순수 할당

두 번째 가상 테스트 사례에서는 어떤 명령도 실행하지 않으면서 어떻게든 실행 중에 바이트 단위의 메모리를 할당할 수 있는 이상적인 설정을 살펴보았습니다. 아래 그래프는 최대 43메가바이트의 메모리를 할당하는 데 드는 비용을 Y축에 표시한 것입니다. 

이전 사례에서 보았듯이 메모리 할당 비용은 실행 중에 점점 더 많은 메모리가 할당됨에 따라 비선형적으로 확장됩니다. 그러나 명령어 실행과는 달리 메모리 할당에 대한 비선형 스케일업은 비용의 상단에 도달할수록 훨씬 더 높아집니다.

여러 가지 주요 차원을 개별적으로 살펴보았으므로 이제 좀 더 현실적인(그러나 여전히 가상의) 워크로드를 살펴볼 수 있습니다.

합성 사례 3: 할당 금액이 다른 인스트럭션 

명령어와 메모리 비용을 개별적으로 살펴보고 더 많은 명령어가 실행되거나 더 많은 메모리가 할당될 때 비용이 어떻게 변하는지를 살펴봤으므로 이제 이를 종합하여 비용 환경을 분석할 수 있습니다. 아래 그래프는 다양한 명령어 수에 대해 명령어 수가 증가함에 따라 Y축의 비용과 X축의 비용을 보여줍니다.

한 가지 주목해야 할 점은 일정 기간(명령어 수) 동안 비용이 매우 억제되어 있다가 그 이후부터 기하급수적으로 증가한다는 점입니다. 이는 앞서 언급했던 계산 사용 규모의 낮은 끝에서 비용을 낮게 책정하거나 공격적으로 책정할 수 있다는 점으로 돌아가는데, 트랜잭션 내 계산 사용량이 증가하면 해당 계산 비용도 함께 급격히 증가하여 비용 모델에서 고려하지 않은 계산 아티팩트나 과소 책정 가능성을 상쇄할 수 있기 때문입니다.

실제 테스트 및 튜닝

시스템의 계산 및 비계산 측면 모두에서 Sui 가스 모델을 조정하고 발전시키는 것은 현재 모델이 실제 세계에서 어떻게 작동하는지 지속적으로 평가하고 개발자와 사용자의 문제점이 어디에 있는지 파악해야 하는 지속적인 과정입니다. 저희는 쉽게 프로그래밍할 수 있고, 좋은 프로그래밍 습관을 최대한 방해하지 않으며, 좋은 행동을 장려하는 공정하고 이해하기 쉬운 모델을 지속적으로 개발해 나갈 계획입니다. 

미래를 내다볼 때, 기회 비용의 개념과 가스 요금과 가스 모델이 Sui 에서 실행의 병렬 특성과 어떻게 관련되어 있는지는 공유 객체와 상호 작용하거나 사용하는 데 추가 비용이 발생하는 방식에 대해 생각해야 함을 의미합니다. 공유 객체 공유 객체와 상호 작용하거나 사용하는 데 추가 비용이 발생하는 방법을 고려해야 합니다.

또한 네트워크 대역폭과 같은 트랜잭션의 비계산 비용을 충당하기 위해 추가 비용을 추가해야 할 것입니다. 트랜잭션 크기, 입력 객체의 수와 크기, 입력 인자의 수와 크기를 트랜잭션 실행의 전체 비용에 반영할 수 있는 방법을 살펴볼 것입니다.

Sui 에서 진화하는 가스 이야기는 현재 진행 중인 과정이며, 가스 모델을 개선할 수 있는 부분과 거래에서 가스를 사용하는 방식에 대한 도구와 더 나은 가시성 및 정보가 유용한 부분에 대한 커뮤니티의 피드백을 소중하게 생각합니다.