You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optimization:
Dynamic adjustment of TxFeeRebateRatio.
Parameter Tuning:
The ratio could be increased during times of low network congestion to incentivize dApp development or decreased during high congestion to prioritize network stability.
During periods of low network congestion, increasing the TxFeeRebateRatio can serve as an incentive for developers to build and deploy decentralized applications (dApps) on the network. A higher rebate ratio means that developers will receive a larger portion of transaction fees, potentially making it more attractive to develop and maintain dApps on the network.
On the other hand, when network congestion levels rise, decreasing the TxFeeRebateRatio can help to alleviate congestion and maintain network stability. By reducing the portion of fees rebated to developers, validators can prioritize transaction processing and ensure that critical network functions remain operational. This adjustment can help prevent network overload and ensure that essential transactions, such as transfers and block confirmations, continue to be processed efficiently.
In addition to balancing network congestion and incentivizing dApp development, dynamic adjustment of the TxFeeRebateRatio can also contribute to fair compensation for validators. By adjusting the rebate ratio based on network conditions, validators can ensure that their rewards are commensurate with their contributions to network stability and security. This dynamic compensation mechanism can help maintain a healthy and engaged validator community, which is essential for the long-term sustainability of the network.
Optimization:
InflationRewardsRatio could be adjusted regularly based on network metrics.
This could involve an automated system that adjusts the ratio based on factors like total number of transactions, average gas usage, or overall network growth rate.
Parameter Tuning:
By increasing the InflationRewardsRatio during periods of high network growth, the system incentivizes more Dapps to join the network and participate in its activities. This increased Dapps base leads to a larger pool of potential validators and transaction fees, potentially boosting overall chain revenue.
3)Transaction Fees
MinimumTxFee = (MinConsensusFee * TxGasLimit) + Σ[flatfee(ContractAddress_msg)] for each msg
Optimization:
Implementing dynamic adjustment of MinConsensusFee based on network load.
Parameter Tuning:
MinConsensusFee can be increased during peak times to discourage spam transactions and lowered during off-peak times to encourage network usage.
Dynamically adjusting MinConsensusFee based on network load and congestion can optimize transaction throughput and maintain network health.
Adjusting InflationBlockRewards based on the current inflation rate, overall network value, and transaction volume.
Periodic review and adjustment (e.g., every hour or daily) of this parameter could help maintain a balance between ensuring transaction affordability and controlling inflation.
This analysis also aligns with the Inflationary Rewards tuning in 2) point.
Metric Calculations
GetNetworkCongestionMetric
This function measure network congestion based on the number of transactions in the mempool, block size and time taken for transactions to be included in a block.
func (kKeeper) GetNetworkCongestionMetric(ctx sdk.Context) float64 {
//granular metric - the number of pending transactionspendingTxCount:=k.GetPendingTxCount(ctx)
// Calculate congestion metric using the granular metriccongestionMetric:=float64(pendingTxCount) /float64(k.GetMaxMempoolSize(ctx))
returncongestionMetric
}
func (kKeeper) GetNetworkCongestionMetric(ctx sdk.Context) float64 {
// Calculate average transaction lifetime in the mempoolavgTxlifetime:=calculateAverageTxlifetime(k.GetMempool(ctx))
// Use average transaction lifetime as a factor in the congestion metriccongestionMetric:=avgTxlifetime*k.GetPendingTxCount(ctx) /float64(k.GetMaxMempoolSize(ctx))
returncongestionMetric
}
funccalculateAverageTxlifetime(mempoolMempool) float64 {
// Initialize variables to track total lifetime and number of transactionstotalTxlifetime:=0.0numTx:=0// Iterate through transactions in the mempoolfor_, tx:=rangemempool.Txs {
// Calculate the transaction lifetime for the current transactiontxLifetime:=tx.CreationTime.Sub(time.Now())
// Update the total transaction lifetime and number of transactionstotalTxlifetime+=txLifetime.Seconds()
numTx++
}
// Calculate the average transaction lifetimeavgTxlifetime:=totalTxlifetime/float64(numTx)
returnavgTxlifetime
}
func (kKeeper) GetNetworkCongestionMetric(ctx sdk.Context) float64 {
// Calculate a dynamic congestion threshold based on recent network activitydynamicThreshold:=calculateDynamicThreshold(k.GetRecentTxHistory(ctx))
// Use the dynamic threshold in the congestion metric calculationcongestionMetric:=k.GetPendingTxCount(ctx) /float64(dynamicThreshold)
returncongestionMetric
}
funccalculateDynamicThreshold(txHistory []Transaction) float64 {
// Calculate the average transaction arrival rate over the recent historyaverageTxArrivalRate:=calculateAverageTxArrivalRate(txHistory)
// Calculate the target mempool occupancy based on the average arrival ratetargetMempoolOccupancy:=calculateTargetMempoolOccupancy(averageTxArrivalRate)
// Calculate the dynamic threshold based on the target occupancy and maximum mempool sizedynamicThreshold:=targetMempoolOccupancy*k.GetMaxMempoolSize(ctx)
returndynamicThreshold
}
funccalculateTargetMempoolOccupancy(averageTxArrivalRatefloat64, networkLoadMetricfloat64) float64 {
// Define a base safety marginbaseSafetyMargin:=0.2// Calculate a dynamic safety margin based on transaction arrival ratedynamicSafetyMargin:=0.1* (averageTxArrivalRate-targetTxProcessingRate) /targetTxProcessingRate// Apply the combined safety marginsafetyMargin:=baseSafetyMargin+dynamicSafetyMargin// Calculate the target mempool occupancytargetMempoolSize:=targetTxProcessingRate*avgTxSize*float64(time.Second) *networkLoadMetrictargetMempoolOccupancy:=targetMempoolSize/float64(k.GetMaxMempoolSize(ctx))
targetMempoolOccupancy= (1.0-safetyMargin) *targetMempoolOccupancyreturntargetMempoolOccupancy
}
calculateAverageTxArrivalRate: This function analyzes the timestamps of recent transactions to determine the average number of transactions arriving per unit of time.
calculateAverageTxlifetime: This function takes a Mempool object as input and calculates the average transaction lifetime by iterating through the transactions in the mempool. For each transaction, it calculates the transaction lifetime by subtracting the current time from the transaction's creation time. It then adds the transaction lifetime to a running total and increments a counter for the number of transactions. Finally, it divides the total transaction lifetime by the number of transactions to get the average transaction lifetime.
calculateTargetMempoolOccupancy: This function determines the target mempool occupancy by multiplying the target transaction processing rate by the average transaction size and the network load metric. The result is then divided by the maximum mempool size and multiplied by (1 - safety margin) to apply the combined safety margin. This ensures that the target mempool occupancy is adjusted based on both the network load and the transaction arrival rate. If the arrival rate is higher than the target rate, the safety margin is increased to prevent excessive mempool growth. Conversely, if the arrival rate is lower than the target rate, the safety margin is decreased to allow for more transactions to be held in the mempool.
calculateDynamicThreshold: This function multiplies the target mempool occupancy by the maximum mempool size to determine the dynamic threshold. This ensures that the threshold remains within the bounds of the mempool's capacity.
Measuring Congestion Using Pending Transactions:
The function GetNetworkCongestionMetric, directly utilizes the number of pending transactions in the mempool (pendingTxCount) as a measure of network congestion. This approach provides a simple and immediate indication of the network's workload. A higher number of pending transactions suggests that the network is processing transactions more slowly than they are being submitted, leading to congestion.
Measuring Congestion Using Transaction Lifetime:
The function, GetNetworkCongestionMetric, measures the average transaction lifetime in the mempool (avgTxlifetime) and incorporates it into the congestion metric. Transaction lifetime represents the time a transaction spends in the mempool before being included in a block. A longer transaction lifetime indicates that transactions are taking longer to be processed and confirmed, suggesting network congestion.
Measuring Congestion Using Dynamic Threshold:
The function, GetNetworkCongestionMetric, employs a dynamic congestion threshold (dynamicThreshold) based on recent network activity. This approach adapts the congestion metric to the network's current state and avoids relying on fixed thresholds that may not accurately reflect real-time congestion levels.
Calculating Dynamic Threshold:
The calculateDynamicThreshold function determines the dynamic threshold based on the average transaction arrival rate (averageTxArrivalRate) and the target mempool occupancy (targetMempoolOccupancy). The average arrival rate reflects the network's transaction volume, while the target occupancy represents the desired proportion of the maximum mempool size that should be occupied by pending transactions.
Calculating Target Mempool Occupancy:
The calculateTargetMempoolOccupancy function dynamically calculates the target mempool occupancy based on the average transaction arrival rate (averageTxArrivalRate), network load metric (networkLoadMetric), and safety margins. The network load metric provides an indication of the network's ability to handle transaction volume, while the safety margins help prevent excessive mempool growth.
2)Network load computation
func (kKeeper) GetNetworkLoadMetric(ctx sdk.Context) float64 {
// Get CPU usagevarru syscall.Rusageerr:=syscall.Getrusage(syscall.RUSAGE_SELF, &ru)
iferr!=nil {
return0
}
cpuTime:=ru.Utime.Sec+ru.Stime.SeccpuPercentage:=float64(cpuTime) /float64(time.Second) *100// Get bandwidth usagebytesRead:=ru.Ixrcc.ReadBytesbytesWritten:=ru.Ixwc.WrittenBytesbandwidthUsage:=float64(bytesRead+bytesWritten) /float64(time.Second)
// Calculate network load metricloadMetric:= (cpuPercentage+bandwidthUsage) /2returnloadMetric
}
func (kKeeper) GetMaxResourceCapacity(ctx sdk.Context) float64 {
// Get maximum CPU capacitycpuCount:=runtime.NumCPU()
maxCPUCapacity:=float64(cpuCount) *100// Get maximum bandwidth capacityvarnetworkInterfaces []net.Interfaceinterfaces, err:=net.Interfaces()
iferr!=nil {
return0
}
for_, iface:=rangeinterfaces {
ififace.Flags&net.FlagUp==0 {
continue
}
linkAttrs, err:=iface.LinkAttrs()
iferr!=nil {
continue
}
maxBandwidthCapacity:=linkAttrs.Speedbreak// Assuming single network interface
}
// Calculate network load metricmaxResourceCapacity:=maxCPUCapacity+maxBandwidthCapacityreturnmaxResourceCapacity
}
GetNetworkGrowthMetric
This function calculate network growth based on the increase in the number of active contract addresses and total transactions over time.
//Get the current block heightcurrentBlockHeight:=tendermintClient.GetBlockHeight(ctx)
// Get the block height at a specific time interval in the pastpreviousBlockHeight:=tendermintClient.GetBlockHeightByTime(ctx, time.Now().Add(-time.Hour))
// Query the blockchain to count transactions in each blockcurrentTxCount:=0previousTxCount:=0forblockHeight:=currentBlockHeight; blockHeight>=previousBlockHeight; blockHeight-- {
block:=tendermintClient.GetBlockByHeight(ctx, blockHeight)
ifblock.TxCount>0 {
ifblockHeight==currentBlockHeight {
currentTxCount=block.TxCount
} else {
previousTxCount+=block.TxCount
}
}
}
func (kKeeper) GetNetworkGrowthMetric(ctx sdk.Context) float64 {
// Calculate the growth rate as the percentage change in transaction countgrowthRate:= (currentTxCount-previousTxCount) /previousTxCount// Convert the growth rate to a percentage and return itgrowthMetric:=growthRate*100returngrowthMetric
}
// Get the current block heightcurrentBlockHeight:=tendermintClient.GetBlockHeight(ctx)
// Get the block height at a specific time interval in the pastpreviousBlockHeight:=tendermintClient.GetBlockHeightByTime(ctx, time.Now().Add(-time.Hour))
// Query the blockchain to count transactions and smart contracts in each blockcurrentTxCount:=0previousTxCount:=0currentSCCount:=0previousSCCount:=0forblockHeight:=currentBlockHeight; blockHeight>=previousBlockHeight; blockHeight-- {
block:=tendermintClient.GetBlockByHeight(ctx, blockHeight)
ifblock.TxCount>0 {
ifblockHeight==currentBlockHeight {
currentTxCount=block.TxCount
} else {
previousTxCount+=block.TxCount
}
}
// Count smart contracts deployed in the blockfor_, tx:=rangeblock.Txs {
iftx.Type==types.TxTypeContract {
ifblockHeight==currentBlockHeight {
currentSCCount++
} else {
previousSCCount++
}
}
}
}
func (kKeeper) GetNetworkGrowthMetric(ctx sdk.Context) float64 {
// Calculate the growth rate for transactions and DappstxGrowthRate:= (currentTxCount-previousTxCount) /previousTxCountscGrowthRate:= (currentSCCount-previousSCCount) /previousSCCount//weight for transactions and Dapp growth rate on the chaingrowthMetric:= (0.7*txGrowthRate) + (0.3*scGrowthRate)
growthMetric*=100// Convert to percentagereturngrowthMetric
}
https://github.com/orgs/archway-network/discussions/30
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
1)contractfeerewards = (TxFees * TxFeeRebateRatio) * (ContractTxGasUsed / TxGasUsed)
Optimization:
Dynamic adjustment of TxFeeRebateRatio.
Parameter Tuning:
The ratio could be increased during times of low network congestion to incentivize dApp development or decreased during high congestion to prioritize network stability.
During periods of low network congestion, increasing the TxFeeRebateRatio can serve as an incentive for developers to build and deploy decentralized applications (dApps) on the network. A higher rebate ratio means that developers will receive a larger portion of transaction fees, potentially making it more attractive to develop and maintain dApps on the network.
On the other hand, when network congestion levels rise, decreasing the TxFeeRebateRatio can help to alleviate congestion and maintain network stability. By reducing the portion of fees rebated to developers, validators can prioritize transaction processing and ensure that critical network functions remain operational. This adjustment can help prevent network overload and ensure that essential transactions, such as transfers and block confirmations, continue to be processed efficiently.
In addition to balancing network congestion and incentivizing dApp development, dynamic adjustment of the TxFeeRebateRatio can also contribute to fair compensation for validators. By adjusting the rebate ratio based on network conditions, validators can ensure that their rewards are commensurate with their contributions to network stability and security. This dynamic compensation mechanism can help maintain a healthy and engaged validator community, which is essential for the long-term sustainability of the network.
2)Inflationary Rewards
contractinflationrewards = (MintedTokens * InflationRewardsRatio) * (ContractTotalGasUsed / BlockGasLimit)
Optimization:
InflationRewardsRatio could be adjusted regularly based on network metrics.
This could involve an automated system that adjusts the ratio based on factors like total number of transactions, average gas usage, or overall network growth rate.
Parameter Tuning:
By increasing the InflationRewardsRatio during periods of high network growth, the system incentivizes more Dapps to join the network and participate in its activities. This increased Dapps base leads to a larger pool of potential validators and transaction fees, potentially boosting overall chain revenue.
3)Transaction Fees
MinimumTxFee = (MinConsensusFee * TxGasLimit) + Σ[flatfee(ContractAddress_msg)] for each msg
Optimization:
Implementing dynamic adjustment of MinConsensusFee based on network load.
Parameter Tuning:
MinConsensusFee can be increased during peak times to discourage spam transactions and lowered during off-peak times to encourage network usage.
Dynamically adjusting MinConsensusFee based on network load and congestion can optimize transaction throughput and maintain network health.
4)Minimum Consensus Fee
MinConsensusFee = InflationBlockRewards / (BlockGasLimit * (1 - TxFeeRebateRatio))
Adjusting InflationBlockRewards based on the current inflation rate, overall network value, and transaction volume.
Periodic review and adjustment (e.g., every hour or daily) of this parameter could help maintain a balance between ensuring transaction affordability and controlling inflation.
This analysis also aligns with the Inflationary Rewards tuning in 2) point.
This function measure network congestion based on the number of transactions in the mempool, block size and time taken for transactions to be included in a block.
calculateAverageTxArrivalRate: This function analyzes the timestamps of recent transactions to determine the average number of transactions arriving per unit of time.
calculateAverageTxlifetime: This function takes a Mempool object as input and calculates the average transaction lifetime by iterating through the transactions in the mempool. For each transaction, it calculates the transaction lifetime by subtracting the current time from the transaction's creation time. It then adds the transaction lifetime to a running total and increments a counter for the number of transactions. Finally, it divides the total transaction lifetime by the number of transactions to get the average transaction lifetime.
calculateTargetMempoolOccupancy: This function determines the target mempool occupancy by multiplying the target transaction processing rate by the average transaction size and the network load metric. The result is then divided by the maximum mempool size and multiplied by (1 - safety margin) to apply the combined safety margin. This ensures that the target mempool occupancy is adjusted based on both the network load and the transaction arrival rate. If the arrival rate is higher than the target rate, the safety margin is increased to prevent excessive mempool growth. Conversely, if the arrival rate is lower than the target rate, the safety margin is decreased to allow for more transactions to be held in the mempool.
calculateDynamicThreshold: This function multiplies the target mempool occupancy by the maximum mempool size to determine the dynamic threshold. This ensures that the threshold remains within the bounds of the mempool's capacity.
Measuring Congestion Using Pending Transactions:
The function GetNetworkCongestionMetric, directly utilizes the number of pending transactions in the mempool (pendingTxCount) as a measure of network congestion. This approach provides a simple and immediate indication of the network's workload. A higher number of pending transactions suggests that the network is processing transactions more slowly than they are being submitted, leading to congestion.
Measuring Congestion Using Transaction Lifetime:
The function, GetNetworkCongestionMetric, measures the average transaction lifetime in the mempool (avgTxlifetime) and incorporates it into the congestion metric. Transaction lifetime represents the time a transaction spends in the mempool before being included in a block. A longer transaction lifetime indicates that transactions are taking longer to be processed and confirmed, suggesting network congestion.
Measuring Congestion Using Dynamic Threshold:
The function, GetNetworkCongestionMetric, employs a dynamic congestion threshold (dynamicThreshold) based on recent network activity. This approach adapts the congestion metric to the network's current state and avoids relying on fixed thresholds that may not accurately reflect real-time congestion levels.
Calculating Dynamic Threshold:
The calculateDynamicThreshold function determines the dynamic threshold based on the average transaction arrival rate (averageTxArrivalRate) and the target mempool occupancy (targetMempoolOccupancy). The average arrival rate reflects the network's transaction volume, while the target occupancy represents the desired proportion of the maximum mempool size that should be occupied by pending transactions.
Calculating Target Mempool Occupancy:
The calculateTargetMempoolOccupancy function dynamically calculates the target mempool occupancy based on the average transaction arrival rate (averageTxArrivalRate), network load metric (networkLoadMetric), and safety margins. The network load metric provides an indication of the network's ability to handle transaction volume, while the safety margins help prevent excessive mempool growth.
2)Network load computation
This function calculate network growth based on the increase in the number of active contract addresses and total transactions over time.
Beta Was this translation helpful? Give feedback.
All reactions