각 블록에 대한 릴레이 체인 거래 수수료 및 거래 한도
자원 사용 제한
거래 수수료 설정
시간에 따라 거래 수수료 조정
국고
요약:
이전 Web3 리서치 시리즈｜Polkadot Token Economics(1부)에서 자세히 설명했습니다.
1. 토큰 DOT의 조직 구조 및 주요 기능
보조 제목
텍스트
각 블록에 대한 릴레이 체인 거래 수수료 및 거래 한도
릴레이 체인 트랜잭션에서 구현하려는 일부 속성은 다음과 같습니다.
1. 각 릴레이 체인 블록에는 블록 응답 생성 지연을 피하기 위해 블록에 대한 요청이 덜 강력한 노드에서도 효율적으로 처리되도록 일정량의 리소스가 제공되어야 합니다.
2. 릴레이 체인 상태의 성장 속도는 제한적입니다. 2'. 릴레이 체인 상태의 절대 크기가 제한되면 더 좋을 것입니다.
3. 각 블록 쌍에는 가용성이 보장되고 우선 순위가 높은 트랜잭션(예: 위법 행위 보고)이 있는 특정 수의 작업이 있습니다.
4. 블록은 일반적으로 채워지는 것과 거리가 멀기 때문에 활동 급증을 효율적으로 처리하고 억제 시간이 짧습니다.
5. 수수료는 특정 트랜잭션 tx에 대한 수수료를 몇 분 안에 정확하게 예측할 수 있을 정도로 천천히 변경됩니다.
6. 모든 거래에 대해 거래 수수료 수준은 블록 생산자가 블록을 실행하여 받는 보상보다 엄격히 높아야 합니다. 그렇지 않으면 블록 생산자는 가짜 거래로 블록을 채우도록 장려됩니다.
7. 모든 트랜잭션에 대해 충분히 높은 운영 보상은 블록 생산자의 합의이며 그 보상은 트랜잭션을 블록에 포함하도록 장려하기에 충분하지만 블록 생산자가 포크를 만들고 블록을 훔치도록 동기를 부여하기에는 충분하지 않습니다. 이전 블록의 트랜잭션 .
실제로 이것은 추가 거래를 포함하는 것에 대한 인식된 한계 보상이 해당 처리에 대한 한계 비용보다 높지만 전체 블록을 생성하는 총 보상은 빈 블록을 생성하는 보상보다 크지 않다는 것을 의미합니다(심지어 팁이 계산될 때).
현재 속성 1~6(2' 제외)을 만족시키는 데 중점을 두고 있으며 추가 업데이트를 위해 속성 2'와 7을 유지합니다. 속성 2에 대한 추가 분석도 수행해야 합니다.
우리는 릴레이 체인 블록에서 처리되는 거래량을 두 가지 방법으로 규제할 수 있습니다: 한도 부과 및 거래 수수료 수준 조정. 리소스 사용에 엄격한 제한을 부과하여 위의 속성 1~3을 충족하고 요금을 조정하여 속성 4~6을 달성합니다. 이 두 가지 기술은 다음 두 하위 섹션에서 설명합니다.
자원 사용 제한
트랜잭션을 처리할 때 소비될 수 있는 네 가지 리소스를 식별했습니다.
1. 길이: 릴레이 체인 블록에서 tx의 데이터 크기(바이트 단위),
2. 시간: 가져오기 시간(i/o 및 cpu),
3. 메모리: 필요할 때 실행할 메모리 양
4. 상태: 상태 저장 공간이 증가했습니다.
한 번만 소비되는 다른 세 가지 리소스와 달리 상태 스토리지는 네트워크에서 영구적인 비용이 발생합니다. 따라서 상태 저장을 위해 수수료를 실제 거래 비용과 더 잘 일치시키고 상태 크기가 제한되지 않도록 다른 메커니즘을 임대하거나 사용할 수 있습니다. 이를 위해서는 추가 고려가 필요합니다. 우리는 또한 국가 성장에 엄격한 제한을 두지 않고 대신 수수료를 통해 통제하는 다른 메커니즘을 고려할 수 있습니다. 생기다.
조정 가능한 매개변수: 현재 블록을 처리할 때 리소스 사용에 대해 다음 제한을 권장합니다. 이러한 매개 변수가 전달되며, 현재로서는 청크를 처리할 때 리소스 사용량에 대해 다음과 같은 제한을 권장합니다. 이러한 매개변수는 실제 데이터 또는 더 복잡한 메커니즘을 기반으로 하는 거버넌스를 통해 추가로 조정됩니다.
1. 길이: 5MB,
2. 시간: 2초
3. 메모리: 10GB
4. 상태: 1MB 증가
원칙적으로 트랜잭션은 길이, 유형, 입력 매개 변수 및 현재 상태에 따라 다음 세 가지 리소스 중 일정량을 소비합니다. 그러나 단순화를 위해 각 트랜잭션 유형에 대한 입력 매개변수의 바이트 길이와 최악의 상태만 고려하기로 결정했습니다. 따라서 트랜잭션을 길이, 유형 및 매개변수 길이별로 분류하고 테스트(최악의 시나리오 기반)를 실행하여 일반적인 리소스 사용량을 확인합니다.
현재 우리는 블록이 각 트랜잭션을 순차적으로 처리하는 모델을 연구하고 있습니다. 따라서 위 블록의 메모리 제한을 보장하려면 모든 트랜잭션이 메모리 제한을 준수하는지 확인하는 것으로 충분합니다. 우리는 모든 일이 발생하는지 확인합니다. 그러나 앞으로는 병렬 처리를 고려할 수 있습니다.
모델을 더욱 단순화하기 위해 트랜잭션 가중치를 매개변수로 정의하여 트랜잭션의 점유 시간과 상태 증가를 캡처합니다. 특히 트랜잭션 가중치를 일반적인 에포크 및 상태 사용의 최대값으로 정의하고 각 가중치는 해당 블록 제한의 일부로 측정됩니다. 그런 다음 트랜잭션 모음이 주어지면 한편으로는 길이와 다른 한편으로는 가중치를 합산하고 두 제약 조건이 모두 준수되는 경우에만 동일한 블록에 있도록 허용합니다. 이는 모든 청크에서 준수해야 하는 리소스 사용에 대한 엄격한 제약 조건입니다.
리소스 사용에 대한 추가 제한 사항을 추가했습니다. 우리는 어부들이 보고하는 우선 순위가 높은 거래인 "정상적인" 거래와 "실행 가능한" 거래를 구분합니다. 일반 트랜잭션은 길이와 가중치의 합이 모두 해당 한도의 75% 미만인 경우에만 동일한 블록 내에서 수집 및 패키징할 수 있습니다. 이는 각 블록에 실행 가능한 트랜잭션을 위한 공간이 보장되도록 하기 위한 것입니다(리소스의 최소 25%가 남아 있음).
해당 트랜잭션에 대해 설정된 일반적인 리소스 사용량 세부 정보입니다. 길이는 검사를 통해 쉽게 결정됩니다. 시간 및 메모리 사용을 위해 릴레이 체인에 대해 최악의 상태를 준비했습니다(이 트랜잭션 유형을 가져오기 위한 시간 및 메모리 요구 사항이 가장 큰 상태여야 함). 주어진 트랜잭션 유형에 대해 가장 긴 가져오기 시간이 걸리는 상태를 사용하여 10,000개의 트랜잭션을 생성하고 Wasm 환경에서 리소스 사용의 평균 및 표준 편차를 측정합니다. 표준 편차가 평균의 10%보다 크면 샘플 공간을 10k 이상으로 늘립니다. 마지막으로 최악의 트랜잭션에 대한 대규모 샘플을 확인하여 상태를 개선합니다.
거래 수수료 설정
위의 모델에 따라 트랜잭션 유형, 트랜잭션 시간 길이 및 가중치(위에서 이미 정의된 매개변수)의 세 가지 매개변수를 기반으로 트랜잭션 수수료를 설정합니다. 이 수수료 차이는 각 거래에서 발생하는 자원 비용의 차이를 반영하는 데 사용되며, 이를 기반으로 특정 거래 시장 행동을 결정하고 권장하거나 권장하지 않습니다.
앞서 언급했듯이 거래 수수료의 일부는 포괄성을 장려하기 위해 블록 생산자에게 가야 하지만 전부는 아니므로 블록 생산자는 가짜 거래로 블록을 채우는 것을 권장하지 않습니다. 단순화를 위해 우리는 처음에 각 거래 수수료의 20%를 블록 생산자에게 주고 나머지 80%를 재무부에 제공할 것을 제안했습니다. 소각에 대해 더 작은 값을 설정할 수 있지만 인플레이션 비율을 더 잘 제어하기 위해 그렇게 하지 않기로 선택했습니다. 앞으로 우리는 이 비율을 조정할 수 있으며 블록 생산자가 수수료를 조정하지 않고 특정 거래 유형을 포함하도록 장려하기 위해 거래 유형에 따라 다를 수 있습니다.
거래 수수료 계산 공식은 다음과 같습니다.
~에네트워크 트래픽에 따라 시간이 지남에 따라 변경되는 트랜잭션 독립적인 매개변수로, 다음 섹션에서 이 매개변수에 대해 설명합니다. 매개변수
거래 유형에 따라 다르며 특히 비즈니스 거래의 경우 현재
0으로 설정합니다.
직관적으로블록 생산자의 처리 비용을 충당하는 반면
，
블록 내에서 트랜잭션을 처리하는 것과 블록 내에서 다른 트랜잭션을 처리하는 기회 비용을 다룹니다.
시간에 따라 거래 수수료 조정
블록체인에서 트랜잭션 수요는 종종 매우 불규칙합니다. 한편으로 거래는 하루 중 몇 시간 또는 매월 며칠 동안 활동이 최고조에 달합니다. 반면에 장기적인 추세가 있습니다. 이러한 요소를 염두에 두고 시간이 지남에 따라 거래 수수료를 자동으로 업데이트하는 메커니즘이 필요합니다. 수요와 공급의 법칙에 따르면 수수료를 올리면 수요가 줄어들고 그 반대도 마찬가지입니다.
급증하는 활동에 대처하기 위해 우리는 빠르게 증가하는 거래 수수료 또는 잠재적으로 연장되는 거래 포함 시간의 균형을 맞춰야 합니다. 이 두 가지 모두 해로운 영향을 미칩니다. 우리는 두 가지 메커니즘을 제안합니다. 첫 번째는 활동의 최고점과 최저점과 동일한 속도로 가격을 매우 빠르게 조정합니다. 두 번째는 장기적인 추세에 따라 천천히 조정하고 팁을 사용하여 사용자가 피크 시간대에 대기 시간을 제어할 수 있는 가능성을 제공하는 것입니다. 힌트와 함께 느린 조정 메커니즘을 사용하는 것이 좋지만 두 메커니즘의 무결성에 대한 세부 정보를 제공합니다.
가격을 빠르게 조정
이 메커니즘에서 거래 수수료는 시간이 지남에 따라 크게 다르지만 모든 사용자에 대해 블록당 고정(팁 없음)됩니다.
블록에서 허용되는 모든 트랜잭션의 길이와 가중치의 합계에 엄격한 제한을 두었다는 점을 상기하십시오. 우리는 또한 "정상적인" 트랜잭션(비운영 트랜잭션)의 길이와 가중치의 합을 첫 번째 제한의 75%로 두 번째 하드 제한을 설정합니다.
정의: 블록의 포화 수준(정상 트랜잭션과 관련)을 0과 1 사이의 십진수 s로 정의합니다. 이는 정상 트랜잭션의 한계가 포화 상태에서 얼마나 떨어져 있는지를 설명합니다. 구체적으로, 블록 B의 포화도는
정상적인 길이 범위 내에서 정상적인 거래를 위한 블록 길이 제한은 총 길이 제한의 75%이며, 일반 무게 제한은 총 무게 제한의 75%입니다.
조정 가능한 매개변수: s*는 대상 블록 포화도를 나타냅니다. 이는 예상되는 블록 포화도 수준의 장기 평균(정상 거래 대비)입니다. 우리는 처음에 s* = 0.25를 제안하여 블록이 평균 25% 채워지고 시스템이 평균 일반 트랜잭션 수의 최대 4배까지 급증하는 급증을 처리할 수 있도록 했습니다. 성수기 동안 관찰된 거래량 대 평균 거래량을 기준으로 조정이 이루어질 수 있으며 일반적으로 성수기 동안 더 높은 평균 수수료와 더 긴 거래 포함 시간 사이에 균형이 있습니다.
거래 수수료는 다음과 같이 계산됩니다.
비트랜잭션.s를 현재 블록의 채도라고 합니다. s > s*인 경우 흐름을 약간증가하는 경우
조정 가능한 매개변수: v를 거래 수수료 조정 속도를 제어하는 거래 수수료 변동 계수라고 합니다. 우리는다음과 같이 블록에서 업데이트합니다.
, 다음과 같은 속성이 있습니다.
v의 값이 작다고 가정하면 매개변수는
의 상대적인 변화는 대략적으로 차이(ss*)에 비례합니다.
일정 기간 동안 k개의 블록이 생성되고 평균 포화도가
, 그런 다음 동안
매개변수의 상대적인 변화는 대략적으로 차이의 k배(average-s*)에 비례합니다.
변동 계수 v를 선택하는 방법은 무엇입니까? 해당 기간 동안 100% 포화 상태인 경우에도 k 블록의 기간 동안 수수료가 분수 p 이상 변화하지 않기를 원한다고 가정합니다. 우리는 공식을 얻습니다
일정 기간 동안 k개의 블록이 생성되고 평균 포화도가
, 그런 다음 동안
매개변수의 상대적인 변화는 대략적으로 차이의 k배(average-s*)에 비례합니다.
변동 계수 v를 선택하는 방법은 무엇입니까? 해당 기간 동안 100% 포화 상태인 경우에도 k 블록의 기간 동안 수수료가 분수 p 이상 변화하지 않기를 원한다고 가정합니다. 우리는 공식을 얻습니다
예를 들어 특정 트랜잭션이 피크 시간 동안 최대 k = 20 블록을 기다려야 하고 이 기간 동안 수수료가 5%(p = 0.05) 증가하면 이를 사용자에게 불공평하다고 간주한다고 가정합니다. s* = 0.25인 경우 위 공식은 다음과 같습니다.
이 메커니즘에서 수수료는 단기적으로 거의 일정하게 유지되며 장기적인 추세에만 적응합니다. 우리는 성수기 동안 포함 시간이 길 수 있다는 사실을 받아들여야 하며 포함을 우선시하는 시장을 구축하기 위해 거래 포함 팁을 허용해야 합니다.
위와 동일한 공식을 사용하여 각 블록의 거래 수수료를 업데이트합니다.
더 작은 변동 계수 v를 선택하지 않는 한. 예를 들어, 수수료가 하루에 최대 30%까지 달라지기를 원하고 약 k = 14000 블록이 하루에 생성된다고 가정합니다. s ∗ = 0.25이면 다음을 얻습니다.
거래 수수료는 기본 가격으로 간주됩니다. 사용자가 원하는 양의 토큰을 자유롭게 넣거나 0으로 둘 수 있는 "팁"이라는 트랜잭션의 다른 필드가 있습니다. 블록 생산자는 표준 20% 수수료 외에 100% 팁을 받기 때문에 큰 팁이 있는 포켓 거래에 대한 인센티브가 있습니다. 이 경우 시장 상황과 거래 규모에 따라 팁에 대한 실시간 조언을 사용자에게 제공할 수 있는 소프트웨어가 있어야 합니다. 그러나 대부분의 경우 프롬프트가 없어야 합니다.
국고
시스템은 지속적으로 자금을 조달해야 하며 이를 재무부라고 합니다. 이 자금은 소프트웨어 업데이트를 제공하고, 국민투표로 결정된 변경 사항을 적용하고, 매개변수를 조정하고, 일반적으로 시스템을 원활하게 실행하는 개발자에게 비용을 지불하는 데 사용됩니다.
재무부 기금은 두 가지 방법으로 조달됩니다.
새 토큰을 발행하여 인플레이션을 유발합니다.
거래 수수료를 제거하고 그렇지 않으면 소각하도록 설정된 토큰을 삭감합니다.
특히 이러한 자금 조달 방법은 정부가 화폐를 주조하고 세금과 벌금으로 인플레이션을 통제하여 자금을 조달하는 전통적인 방법을 모방합니다.
우리는 새 토큰을 발행하여 자금을 조달할 수 있지만 거래 수수료에서 토큰을 리디렉션하고 그렇지 않으면 파괴될 재무부로 삭감하는 것이 이치에 맞다고 생각합니다.
이를 통해 실제 지분 소각량을 줄여 인플레이션율을 더 잘 제어할 수 있습니다(지분 소각은 디플레이션이며 소각을 유발하는 이벤트를 제어하거나 예측할 수 없음).
대규모 지분 삭감을 초래하는 사건 이후, 코드에 버그가 있거나 참작할 수 있는 상황이 있는 경우 삭감된 지분을 부분적으로 상환하는 것이 종종 바람직합니다. 따라서 DOT를 먼저 태운 다음 주조하는 것보다 국고에서 DOT를 사용하는 것이 더 합리적입니다.
부정 행위나 거래 수수료로 인해 많은 양의 지분이 소각되는 기간이 있다고 가정합니다. 이 사실은 시스템에 문제가 있으며 수정해야 함을 나타냅니다. 따라서 지금은 개발 비용을 지불하고 문제를 해결하기 위해 더 많은 재정적 자금이 필요한 시기입니다.
편집/몰래 지야오
원본 / WEB3 기반
