cryptosnifEthereum vs Solana
Ethereum vs Solana
La revue des sources explique les mécanismes documentés. Les contrôles indépendants du réseau restent à réaliser.
Promesse et périmètre
Cette comparaison examine les mécanismes de frais d'exécution documentés pour Ethereum et Solana. L'objectif est d'identifier comment les frais sont calculés, qui les reçoit, et quelles preuves manquent. Cette analyse ne désigne pas un gagnant basé sur la vitesse, le coût ou la disponibilité. Elle évite également les classements généralisés de sécurité. Le focus reste strictement limité aux spécifications techniques fournies dans les rapports sources.
Mécanismes de frais Ethereum
La documentation d'Ethereum définit le gas comme une mesure de l'effort computationnel. Les frais sont payés en ETH. La base fee est brûlée, ce qui signifie qu'elle est retirée de la circulation, tandis qu'une priority fee va au validateur. Une transaction exécutée ayant échoué peut toujours consommer du gas.
Ces mécanismes n'établissent pas un changement net de l'offre, les coûts actuels des utilisateurs, l'adoption ou le revenu d'un détenteur.
La spécification EIP-1559 épinglée décrit plus loin les frais de gas d'exécution. La priority fee est plafonnée à maxFee moins baseFee. Le gas non utilisé est remboursé au prix effectif du gas. Pour les blocs en cours, la cible est la moitié de la limite de gas du bloc parent. L'ajustement entier de la base fee utilise un dénominateur de 8 avec un incrément minimal vers le haut de 1. La gestion initiale du fork diffère de cette norme. Cette spécification historique utilise la terminologie des mineurs, alors que les rôles actuels des validateurs sont décrits séparément par la documentation proof-of-stake d'Ethereum. Les frais blob, l'émission et les observations réseau actuelles sont hors du périmètre de ce calcul.
Mécanismes de frais Solana
La documentation de Solana décrit des frais payés en SOL avec une base fee et une prioritization fee optionnelle. La base fee est divisée à 50% brûlée et 50% au validateur. La prioritization fee va entièrement au validateur. Ces règles documentées ne mesurent pas les coûts en direct, l'utilisation ou l'émission nette.
Les transactions contiennent des instructions, qui sont les opérations individuelles que les programmes exécutent. L'exécution est atomique, ce qui signifie que toutes les instructions réussissent ou que leurs changements d'état sont annulés. Cette propriété technique ne prouve pas des audits indépendants des applications, l'absence de bugs ou la fiabilité actuelle du réseau.
Agave v4.3.0 calcule la brûlure ordinaire de la base fee avec une arithmétique entière à 50%. Il ajoute la portion de base non brûlée et la totalité de la priority fee à un dépôt collecteur, puis tente ce dépôt. Un dépôt échoué est également brûlé. Selon un feature flag, le destinataire est l'identité du leader ou un collecteur autorisé associé au compte de vote du leader. Cette version client examinée n'établit pas l'activation actuelle des fonctionnalités, les versions déployées, le coût réel des transactions, l'émission totale ou le contrôle bénéfique.
Exemples numériques hypothétiques
Pour illustrer les mécaniques, nous utilisons l'arithmétique originale de Cryptosnif. Toutes les entrées ci-dessous sont hypothétiques et ne représentent pas des données réseau en direct.
Pour Ethereum, supposons gas used 21000, gas limit 30000, base fee 30 gwei, max fee 40 gwei et max priority fee 2 gwei. Cela résulte en un total de 672000000000000 wei (0.000672 ETH). Le montant brûlé est 630000000000000 wei (0.000630 ETH), et la priority fee est 42000000000000 wei (0.000042 ETH). Le remboursement pour 9000 gas non utilisés est 288000000000000 wei (0.000288 ETH), excluant d'autres mécanismes de remboursement. Wei est la plus petite dénomination ETH ; 1 gwei groupe 1000000000 wei, et 1 ETH égale 10^18 wei. À une base fee parent de 30 gwei, une gas limit parent de 30000000 et une cible de 15000000, la prochaine base fee est 33.75 gwei après un bloc parent plein et 26.25 gwei après un vide.
Lamports sont les unités entières utilisées pour la comptabilité des frais SOL. Un collecteur est le compte destiné à recevoir la portion de frais non brûlée. Pour Solana, supposons une base fee hypothétique de 5000 lamports et une priority fee de 1000 lamports avec un dépôt accepté. Le total est 6000 lamports. Le montant brûlé est 2500 lamports, et le collecteur reçoit 3500 lamports. Si le dépôt collecteur échoue, tous les 6000 lamports sont brûlés. Avec une base fee impaire de 5001 lamports et une priority de 1000 lamports, la brûlure du dépôt accepté est floor(5001*50/100)=2500 lamports, et le collecteur reçoit 3501 lamports.
Ces exemples montrent différents inputs de frais et ne peuvent établir un gagnant en termes de coût.
Preuves manquantes et inconnues
Pour les deux actifs, la concentration actuelle de la propriété, les pouvoirs de contrôle privilégiés, l'utilisation mesurée indépendamment, la remédiation des incidents et la liquidité exécutable localement restent non vérifiés dans ce pilote. La couverture des preuves est insuffisante pour un score global. Un mécanisme documenté seul ne peut établir la résilience actuelle ou les rendements attendus. Des observations réseau reproductibles, des cartes de contrôle actuelles, des règles d'approvisionnement documentées et des registres d'incidents indépendants permettraient d'évaluer les vérifications en attente. Sans cela, toute affirmation concernant la performance relative ou la sécurité reste spéculative.
Verdict et comparaison future
Le verdict pour Ethereum et Solana est qu'ils ont des promesses documentées mais nécessitent une vérification indépendante. Aucun score ne peut être attribué en raison de critères essentiels manquants tels que l'identité, l'approvisionnement et le contrôle. Pour effectuer une comparaison future équitable, les analystes doivent attendre des observations réseau reproductibles confirmant le statut de déploiement en direct. Ils doivent également chercher des mesures indépendantes de l'utilisation et des structures de contrôle. Jusqu'alors, les comparaisons doivent rester limitées aux définitions statiques du code et aux calculs hypothétiques présentés ici. Différents inputs de frais pris isolément ne déterminent pas l'efficacité économique ou l'expérience utilisateur.
Les sources de cette analyse
Les titres et résumés des sources sont en anglais.
Ethereum documentation: gas
Ethereum documentation defines gas as a measure of computational effort. Fees are paid in ETH. The base fee is burned and a priority fee goes to the validator. A failed executed transaction can still consume gas. These mechanisms do not establish net supply change, current user costs, adoption or a holder’s income.
Consulter la source primaire ↗Ethereum documentation: proof of stake
Ethereum documentation describes validators staking ETH and checking or proposing blocks. Misbehaviour can lead to destruction of staked ETH. These descriptions identify a security role for ETH but do not measure today’s validator concentration, independent operators, software diversity, realized rewards or resilience.
Consulter la source primaire ↗Solana documentation: transaction fees
Solana documentation describes fees paid in SOL with a base fee and an optional prioritization fee. It states that the base fee is divided 50% burned and 50% to the validator, while the prioritization fee goes entirely to the validator. These documented rules do not measure live costs, utilization or net issuance.
Consulter la source primaire ↗Solana documentation: transactions
Solana documentation describes transactions containing instructions, the individual operations that programs execute. Execution is atomic: all instructions succeed or their state changes revert. This technical property does not prove independent audits of applications, absence of bugs, or present network reliability.
Consulter la source primaire ↗EIP-1559: pinned fee market specification
The pinned EIP-1559 specification describes execution gas fees: the priority fee is capped at maxFee minus baseFee, the base portion is burned, and unused gas is refunded at the effective gas price. For ongoing blocks the target is half the parent gas limit, with integer base-fee adjustment using denominator 8 and a minimum upward increment of 1. Initial fork handling is different. This historical specification uses miner terminology; current validator roles are described separately by Ethereum proof-of-stake documentation. Blob fees, issuance and current network observations are outside this calculation. Original Cryptosnif arithmetic (platform-mechanisms-1), all hypothetical: gas used 21000, gas limit 30000, base fee 30 gwei, max fee 40 gwei and max priority fee 2 gwei give total 672000000000000 wei (0.000672 ETH), burned 630000000000000 wei (0.000630 ETH) and priority 42000000000000 wei (0.000042 ETH). The refund for 9000 unused gas is 288000000000000 wei (0.000288 ETH), excluding any other refund mechanism. One gwei equals 1000000000 wei; one ETH equals 10^18 wei. At parent base fee 30 gwei, parent gas limit 30000000 and target 15000000, the next base fee is 33.75 gwei after a full parent block and 26.25 gwei after an empty one. These inputs are examples and no present fees or net ETH issuance are inferred.
Consulter la source primaire ↗Solana SDK 3.2.0: pinned inflation model
The solana-inflation 3.2.0 source, matched to its package commit, defines a default total annual rate of max(0.015, 0.08*(1-0.15)^year). It also supports disabled, fixed and full inflation configurations. The default total model differs from the separate validator/foundation allocation functions. These are code parameters, not observed mainnet configuration, realized issuance, calendar dates, net supply change or a staking holder's yield. A model year has no calendar origin established in this review. Original Cryptosnif calculation (platform-mechanisms-1) gives default total annual inflation rates 8%, 6.8% and 5.78% at model years 0, 1 and 2, with a 1.5% floor. The reduction is 15% of the rate each model year until the floor, not a reduction of 15 percentage points. This illustrates defaults only, not today's mainnet inflation, a future dated forecast, circulating supply or staking returns.
Consulter la source primaire ↗Agave v4.3.0: pinned transaction fee distribution
Agave v4.3.0 computes the ordinary base-fee burn with integer arithmetic at 50%, adds the unburned base portion and the entire priority fee to a collector deposit, then attempts that deposit. A failed deposit is also burned. Depending on a feature flag, the recipient is the leader identity or a permitted collector associated with the leader's vote account. This reviewed client version does not establish current feature activation, deployed versions, live transaction cost, total issuance or beneficial control. Illustrative inputs stay within non-overflowing fee amounts. Original Cryptosnif arithmetic (platform-mechanisms-1) assumes a hypothetical base fee 5000 lamports and priority fee 1000 lamports with accepted deposit: total 6000, burned 2500, collector 3500 lamports. With a failed collector deposit, all 6000 lamports are burned. With odd base fee 5001 and priority 1000 the accepted-deposit burn is floor(5001*50/100)=2500 and collector 3501. These hypothetical inputs do not establish fees on the live network or a comparison of cost against Ethereum.
Consulter la source primaire ↗