Сколько транзакций в секунду у биткоина
Перейти к содержимому

Сколько транзакций в секунду у биткоина

  • автор:

Что такое транзакции в секунду (TPS)

Скорость обработки транзакций — одна из многих проблем реального мира, которую стремится решить криптовалюта. Время обработки транзакций играет важную роль при отправке оплаты. В традиционных банковских системах, как правило, транзакции обрабатываются долго. А в международных платежах тем более. Однако криптовалюта может решить эту проблему.

В то время как традиционным банкам иногда требовалась целая неделя на проведение платежа, Bitcoin был способен выполнить ту же транзакцию менее чем за час. В этом руководстве мы расскажем, что такое «транзакций в секунду», или TPS, и почему это важно. Причина этого в том, что BTC по-прежнему остается самой популярной криптовалютой, несмотря на то, что является самой медленной.

Что такое транзакции в секунду (TPS)?

Для начала приведем определение количества транзакций в секунду. По большей части эта концепция не требует пояснений. Как следует из названия, термин описывает количество транзакций, которые сеть может обрабатывать в секунду. Количество транзакций в секунду отличается в зависимости от блокчейна. Каждая блокчейн-сеть имеет максимальное и среднее количество TPS. Несмотря на то что Биткоин является крупнейшей криптовалютой, он имеет одно из самых низких значений TPS.

Стоит отметить, что децентрализация криптовалют повлияла на количество транзакций, которые они могут обрабатывать в секунду. Централизованные сервисы (например, VISA) способны обрабатывать от 1500 до 2000 транзакций в секунду. Это делает их намного эффективнее биткоина, а также многих других криптовалют.

Как TPS влияет на скорость работы блокчейн-сетей?

Показатель TPS тесно связан со скоростью работы блокчейн-сети. Как уже упоминалось, TPS показывает, сколько транзакций может быть выполнено за одну секунду. Конечно, TPS — не единственный параметр, используемый для определения скорости работы блокчейна. Другим важным аспектом является время завершения транзакции. Этот показатель определяет, сколько времени требуется для подтверждения транзакции.

Сколько транзакций в секунду может обрабатывать Bitcoin?

Мы уже неоднократно упоминали, что количество транзакций в секунду в Bitcoin очень низкое. Так, средний TPS биткоина составляет 5 транзакций. А максимальное значение TPS в Bitcoin может достигать 7 транзакций.

С момента появления биткоина поступило несколько предложений по увеличению TPS. Некоторые рекомендовали увеличить размер блока в сети Bitcoin, в то время как у других были другие идеи. Однако ни одно из этих предложений не было принято, поскольку сообщество Bitcoin стремится сохранить экосистему нетронутой.

Так, TPS биткоина на низком уровне удерживает отсутствие инноваций. Средний TPS этого блокчейна остается на уровне 5. А между прочим, сейчас существуют блокчейны, которые могут без труда обрабатывать более 60 000 TPS. Например, с момента своего создания Ethereum был способен развивать до 15 TPS. В сентябре 2022 года блокчейн получил обновление, которое изменило его механизм консенсуса с PoW на PoS. И теперь блокчейн может обрабатывать от 20 000 до 100 000 транзакций в секунду.

Имеет ли значение скорость обработки транзакций на блокчейне?

Мы живем в век информации и коммуникации. Люди ожидают, что транзакции будут обрабатываться быстро и без проблем. Поговорка «время — деньги» никогда не была более актуальной. Учитывая все вышесказанное, да, скорость транзакций чрезвычайно важна для успеха конкретной сети.

Теперь, когда в криптоиндустрию пришли миллионы пользователей, высокий показатель TPS приобрел еще большую важность. Чем больше людей используют криптовалюту, тем больше транзакций приходится обрабатывать. Если блокчейн не может обработать их быстро, это приводит к перегрузке сети. Перегрузка сети означает, что транзакциям придется долго ожидать обработки.

При совершении транзакций пользователи платят комиссию за транзакции, которая, как правило, довольно низкая. Это также делает криптовалюты гораздо экономичнее, чем любое традиционное банковское решение. Однако те, кто хотел, чтобы их транзакции обрабатывались быстро, начали платить более высокие комиссии. Идея заключалась в том, что высокие комиссии сделают их транзакцию более привлекательной для майнеров, что и произошло.

К сожалению, когда люди поняли, что более высокая комиссия за транзакции означает более быструю обработку, все они начали платить больше. Это повысило среднюю комиссию до такой степени, что многие не могли позволить себе ее оплачивать. Это лишь еще один пример того, почему количество транзакций в секунду является важным показателем в любом блокчейне.

Как количество транзакций в секунду влияет на масштабируемость блокчейнов?

Еще одна важная концепция криптоиндустрии — это масштабируемость блокчейна. Популярность криптовалют и технологии «блокчейн» продолжает расти, и сетям необходимо справляться с сильным потоком новых пользователей. А это требует увеличения TPS.

Мы уже упоминали, что блокчейны имеют средний и максимальный TPS. Средний TPS — это время, за которое блокчейн обрабатывает регулярный спрос. Однако во времена резких скачков цен или обвалов гораздо больше людей начинают одновременно совершать транзакции. И блокчейн должен быть способен удовлетворить этот спрос, чтобы избежать перегрузки сети.

Какие криптовалюты самые быстрые?

Разработчики поняли, что у биткоина возникнут проблемы с масштабируемостью почти сразу после создания этого актива. Поэтому многие люди начали работать над решениями, которые улучшили бы масштабируемость будущих криптосистем. Шли годы, появились тысячи новых криптовалют, некоторые из которых создали собственные блокчейны. И практически все они работают быстрее, чем Bitcoin.

На сегодняшний день самой быстрой и масштабируемой сетью считает Solana (SOL). Согласно whitepaper проекта, сеть Solana способна обрабатывать до 710 000 транзакций в секунду. Однако это только теоретическое число. Во время тестов скорость обработки легко достигла 65 000 TPS, и разработчики полагают, что сеть смогла бы обрабатывать вплоть до 400 000 TPS. Между тем, в проекте также предусмотрено время завершения блока, которое составляет 21-46 секунд. Как упоминалось ранее, биткоину бы потребовался, по крайней мере, целый час, чтобы достичь тех же показателей.

Также одним из самых быстрых и масштабируемых активов считается Ethereum. После обновления до Ethereum 2.0 проект увеличил свой максимальный TPS до 100 000. Предыдущий показатель TPS этого блокчейна составлял 12-15, так что это настоящее достижение. Однако Ethereum — это очень популярный и широко используемый блокчейн. Ему просто необходим высокий TPS для обработки трафика и микротранзакций из dApps, основанных на смарт-контрактах.

Tps Okx

Еще одним активом, заслуживающим упоминания, является криптовалюта XRP, созданная Ripple. Он использует не традиционную, а собственную технологию «блокчейн» под названием RippleNet. Ripple и XRP подверглись критике за централизацию проекта, однако это по-прежнему одна из самых быстрых сетей. Утверждается, что RippleNet может обрабатывать до 50 000 транзакций в секунду, что значительно выше, чем у Visa или SWIFT.

Погоня за скоростью в криптоиндустрии

Индустрия криптовалют на протяжении многих лет стремилась к скорости и масштабируемости по мере роста спроса. Популярность криптовалют продолжает расти, и неизвестно, насколько высокий TPS может потребоваться для удовлетворения будущего спроса. С учетом сказанного, стремление к большему показателю и TPS, вероятно, продолжится в ближайшие годы.

Приятно сознавать, что сейчас в криптоиндустрии есть решения, которые могли бы удовлетворить спрос всего мира. Это показывает, что отрасль готова к повсеместному использованию.

Часто задаваемые вопросы

Сколько транзакций в секунду совершается в Bitcoin?

Показатель транзакций в секунду в сети Bitcoin очень низок по сравнению с другими проектами. Приблизительный средний показатель TPS составляет 5 транзакций и может доходить до 7. Однако точная цифра иногда варьируется.

Насколько быстро обрабатываются биткоин-транзакции?

Биткоин-транзакции обрабатываются довольно долго. В большинстве случаев транзакция подтверждается в течение часа. Это не так долго, однако по сравнению с другими блокчейнами, такая скорость считается очень медленной. Так, транзакции в сети Bitcoin считаются успешными при наличии шести подтверждений, на что уходит час.

Какая криптовалюта имеет самый высокий TPS?

По состоянию на 2023 год проектом с самым высоким TPS является Solana. В теории эта сеть может обрабатывать сотни тысяч транзакций в секунду. Whitepaper проекта прогнозирует достижение 710 000 TPS, хотя во время тестов максимум составил 65 000.

Хайповые «показатели» и реальные скорости основных криптовалют

Команда опенсорсного проекта Qtum утверждает, что их корпоративный блокчейн QtumX способен обрабатывать «более 10 000» транзакций в секунду (TPS).

Кажется, в гонку за масштабируемостью включился ещё один игрок, и имеет смысл внимательнее изучить, как на самом деле обстоят дела с TPS у основных блокчейнов и криптовалют, и действительно ли их заявленная масштабируемость является подлинной.

Скорость транзакций: насколько это важно?

Масштабируемость - это одна из главных проблем криптовалют, особенно когда речь идет о более старых монетах. Один из первых публичных комментариев к whitepaper биткоина звучал так:

Прошло 10 лет, однако проблема всё ещё есть – матерь всех блокчейнов может работать лишь со скоростью около 7 TPS. В конце 2017 года последствия такого несовершенства привели к ужасным последствиям - комиссия в сети биткоинов выросла до $28, а владельцы биткоина были вынуждены оплачивать её, чтобы их транзакции не занимали несколько дней. Такие проблемы даже привели к хардфорку, результатом которого стала монета Bitcoin Cash (BCH), которая увеличила ёмкость своих блоков до 8 мегабайт.

После биткоина многие новые криптовалюты пытались создать свои собственные блокчейны, которые, как утверждается, быстрее и дешевле. Их основная цель часто заключалась в том, чтобы одолеть централизованную глобальную систему платежей Visa, скорость которой достигает 24 000 TPS (данные IBM 2010 года). Теперь многие блокчейны говорят, что превзошли этот показатель масштабируемости, но, похоже, только на бумаге.

Показатель TPS, время подтверждения транзакций и масштабируемость в целом, конечно, важны - особенно когда речь идёт о долгожданном массовом принятии крипто; однако они не являются единственными критериями, указывающими на достоинства того или иного блокчейна. Многие криптовалюты утверждают, что у них высокий показатель TPS, однако чаще всего он будет зависеть от конкретных условий работы. Обычно такой трафик трудно измерить в реальном времени и в реальном блокчейне, когда сеть не тестовая, и условия в ней не идеальные. В результате этого, конечно же, многие заявленные TPS будут отличаться от действительных значений.

Кроме того, даже при высоком показателе TPS может отсутствовать спрос на транзакции.

Сайт Txstreet четко визуализировал это, представив каждую транзакцию как человека. В этом представлении показано, как «люди-транзакции» заполняют «автобусы» в пространстве блоков биткоина и BCH. У BCH автобусов больше (так же, как и размер его блоков), но мало пассажиров, которые должны заполнить их. У биткоина, напротив, подают только два автобуса, но они заполняются и отправляются быстро, и на тротуаре остаются толпы «людей-транзакций», ожидающих «посадку» на следующий «автобус-блок».

По сообщениям, даже Visa с 24 000 TPS, в среднем обрабатывает всего 2 000 TPS, а в пиковые часы - до 4000 TPS. Иными словами, Visa отправляет столько транзакций, сколько есть спроса в конкретный момент, так как необходимости в большем количестве транзакций просто нет.

Qtum — QTUM

Заявленных TPS: 10000

Разработчики Qtum недавно протестировали эффективность своего блокчейна на виртуальном сервере Amazon EC2 и пришли к выводу, что QtumX «способен обрабатывать более 10 000 TPS». По их словам, высокая скорость блокчейна сразу позволяет подтверждать транзакции, как только они отправляются в сеть.

Важно отметить то, что QtumX не проверялся независимыми экспертами, и поэтому на данный момент невозможно подтвердить такие данные Qtum. В августе 2018 года разработчики Aelf так же, как и QtumX, сообщили о скорости своего блокчейна в 15 000 TPS при первоначальном тестировании.

Ripple — XRP

Заявленных TPS: 50000 (по оценкам – не более 1500)

Как говорит сама компания Ripple, их цифровой актив XRP для трансграничных платежей может «последовательно обрабатывать 1500 транзакций в секунду».

Также, по словам компании, для урегулирования платежей требуется около 4 секунд, в то время как XRP может масштабироваться до 50 000 TPS - «работать с той же пропускной способностью, что и Visa».

Однако следует отметить, что у Ripple просто нет блокчейна. У них есть собственная запатентованная технология - алгоритм согласования протокола Ripple. Часть криптосообщества игнорирует XRP как криптовалюту. (И вообще, однажды Ripple прокололась, обнаружив, что централизованно может вывести из строя чьи-угодно XRP).

Эфириум — ETH

Заявленных TPS: 15

Даже несмотря на большое количество майнеров, эфириум плохо масштабируется: в настоящее время его блокчейн обеспечивает около 20 TPS. Однако ситуация, вероятно, улучшится с переходом от алгоритма proof-of-work (PoW) на алгоритм proof-of-stake (PoS).

Переход на PoS должен произойти с принятием обновления Casper — Friendly Finality Gadget, который будет использовать технологию масштабирования под названием «шардинг».

Однако разработчики эфириума пока отложили обновление Constantinople, и поэтому пока неясно, когда они смогут представить Casper. Однако, по их словам, Casper может появиться уже в этом году.

Заявленных TPS: 3996 (по оценкам – не более 50)

В июле 2018 года технический директор EOS Даниэль Лаример заявил о производительности EOS в 2351 TPS. Однако несколько месяцев спустя компания Whiteblock протестировала блокчейн EOS и выяснила, что в «реальных условиях» производительность EOS «ниже 50 TPS и чуть больше производительности эфириума».

Stellar — XLM

Заявленных TPS: 1000

Stellar (XLM) - это технология платежей, основанная на протоколе компании Ripple. Однако компания Stellar стремится работать с развивающимися рынками и хорошо известными финансовыми учреждениями, а не с банками.

Сообщается, что у Stellar могут быть разные TPS. Так, по словам одного сотрудника компании Light Year, блокчейн Stellar действительно может обрабатывать до 1000 TPS.

А по другим сведениям, представленным исполнительным директором Barclays Africa Стивеном ван Коллером, тестирование прототипа Stellar на облачных серверах Google показало 10 000 TPS.

Лайткоин — LTC

По оценкам – 56 TPS

Блокчейн лайткоина способен обрабатывать 56 TPS. Однако создатель этой монеты Чарли Ли говорит, что TPS лайткоина можно увеличить за счёт применения протокола Lightning Network – так же, как это уже делается с биткоином.

Tron — TRX

Заявленных TPS: 2000

Блокчейн-сеть Tron была запущена в июне 2018 года, и монета мигрировала в неё из сети эфириума. В одном из сообщений компании было сказано, что монета достигла скорости 2000 TPS. В июле CEO Джастин Сан похвастался, что Tron «в 80 раз быстрее эфириума», что могло означать 1200 TPS. Однако такая информация пока не подтверждена независимыми экспертами.

Cardano — ADA

Заявленных TPS: 250

Это платформа для криптовалюты под названием ADA. Не так давно соучредитель компании Чарльз Хоскинсон сказал, что Cardano может обрабатывать от 50 до 250 TPS. По его словам, добавление сайдчейнов в будущем позволит достичь более 5000 TPS. Скромно, и, кажется, реально.

IOTA — MIOTA

Заявленных TPS: 1500 (по оценкам - 12)

Как говорят создатели IOTA, эта криптовалюта вместо обычного блокчейна использует так называемый «клубок», который позволяет достичь «бесконечного масштабирования». Эта сеть, как утверждается, становится быстрее по мере роста количества пользователей.

On Bitcoin transaction sizes — Part 2

Dr. Johannes Hofmann

As intermediate steps towards the goal of building an analytic transaction-throughput model, two previous articles investigated script and witness sizes for the most common Bitcoin transaction types as well as the not yet implemented but highly anticipated Pay-to-Taproot transaction type.

This article builds on previous findings and investigates the sizes of inputs, outputs, and witnesses of different transaction types. To this end, first-principles-based estimates are derived and verified using empirical data. The findings are distilled into libtxsize, a library to give size, weight, and virtual size estimates for transactions with arbitrary inputs, outputs, and witnesses.

This article is structured as follows. First, the general format of transaction inputs, outputs, and witnesses are discussed. The results of this discussion are then integrated with findings from previous articles to derive size estimates for inputs, outputs, and witnesses of different transaction types; with the exception of Pay-to-Taproot, for which no empirical data is available, all estimates are verified using data from Bitcoin’s blockchain. Next, the format of Bitcoin transactions is discussed, and findings about input, output, and witness sizes are integrated to create an analytic model to estimate the size of arbitrary Bitcoin transactions. The article concludes by presenting libtxsize, a library that incorporates all previous insights to automate transaction-size estimates, and a short summary.

Transaction input, output, and witness formats

In the following, the general formats of inputs, outputs, and witnesses are discussed, and the formats’ implications on transaction size are investigated.

Transaction input format

From a high-level viewpoint, each transaction inputs comprises two key pieces of information: a reference to an unspent transaction output (UTXO) and an unlocking-script to satisfy the locking script of the referenced UTXO.

To reference a UTXO, inputs include a 32-byte transaction hash, which is used to identify a previous transaction, and a 4-byte integer, which specifies the position of an output in that transaction.

Unlocking scripts have a variable size, and will be discussed in the following section. For now, it is sufficient to note that the fact that unlocking scripts have a variable size makes it necessary to explicitly encode their size. This is done using a variable-length integer, a data type devised to minimize the size when encoding non-negative integers up to a size of eight bytes. A variable-length integer requires one byte to encode values from 0 to 252; three bytes for 16-bit integers; five bytes for 32-bit integers; and nine bytes for 64-bit integers. In practice, most unlocking scripts are smaller than 253 bytes, so the encoding of the length of the script is typically one byte.

Finally, each input contains a 4-byte sequence number, which is currently used for the replace-by-fee mechanism that allows updating a transaction’s fee to increase the likelihood of it being included in a block.

To summarize, the input size is determined by a fixed component of 40 bytes, comprising the 32-byte hash, the 4-byte position, and the 4-byte sequence number; and a variable one, comprising the unlocking script and the encoding of its length.

Transaction output format

Transaction outputs include two key pieces of information: the amount and the locking script.

The amount of Bitcoin associated with the output is encoded using an 8-byte integer. Like unlocking scripts, locking scripts have a variable size, and will be discussed in the following section. Moreover, outputs include a variable-length integer that encodes the size of the locking script.

In conclusion, the output size is made up of two components: a fixed contribution of eight bytes, corresponding to the encoding of the the amount; and a variable contribution, determined by the unlocking script and the encoding of its length.

Transaction witness format

Witnesses can serve as alternative stores for data to unlock outputs. Each witness contains a variable-length integer to indicate the number of items it contains. The items are of arbitrary size, so each item’s length is encoded using a variable-length integer as well.

Estimating the sizes of different input, output, and witness types

In the following, analytic estimates for input, output, and, where applicable, witness types are derived and compared to empirical data, whenever the latter is available. Note that sizes for locking and unlocking scripts as well as witnesses are based on previous findings (in general, see the table under “Results and Conclusion” of this article; for Pay-to-Taproot, see this article).

Pay-to-Public-Key

Pay-to-Public-Key (P2PK) outputs have a fixed size of 44 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and the 35-byte locking script.

This analytic estimate is validated by the empirical data shown in the figure below, which contains a histogram of the sizes of all P2PK outputs as of block 637,302. Discounting 76-byte outputs, which are an artifact from Bitcoin’s early days when public keys were encoded using the uncompressed SEC format, all outputs have a size of 44 bytes. (For a detailed discussion of the uncompressed SEC format, see “Encoding of Public Keys” in this article.)

The average size of P2PK inputs is about 113.5 bytes: 40 bytes for referencing a UTXO and the sequence number, a one-byte variable-length integer to encode the unlocking script’s size, and the 72.5-byte unlocking script. Note, however, that using the recently introduced low-r optimization, a consistent size of 113 bytes can be achieved for P2PK inputs.

As before, the analytic estimate is validated by empirical data. The figure below shows a histogram of the sizes of all P2PK inputs as of block 637,302. As expected, more than 90% of all inputs have a size of 113 or 114 bytes. Deviations are caused by the DER encoding of ECDSA signatures, which can lead to the addition or subtraction of bytes depending on the (random) signature values. (See “Encoding of Signatures” in this article for a detailed explanation).

Pay-to-Public-Key-Hash

Pay-to-Public-Key-Hash (P2PKH) outputs have a fixed size of 34 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and the 25-byte locking script.

Again, the analytic estimate is corroborated by empirical data, shown in the figure below. The data in the histogram of the size of all P2PKH outputs as of block 637,302 indicates that all such outputs have a size of 34 bytes.

The average size of P2PKH inputs is about 147.5 bytes: 40 bytes for referencing a UTXO and the sequence number, a one-byte variable-length integer to encode the unlocking script’s size, and the 106.5-byte unlocking script. Again, note that using the low-r optimization, a consistent size of 147 bytes can be achieved for P2PKH inputs.

The estimate is supported by empirical data. The figure below shows a histogram of the sizes of all P2PKH inputs as of block 637,302. As expected, the majority of inputs have a size of 147 or 148 bytes. As before, deviations around the estimate are side effects caused by the DER signature-encoding standard. Moreover, the second cluster around 180 bytes can be neglected, for it is an artifact from Bitcoin’s early days where public keys in P2PKH inputs were encoded using the uncompressed SEC format.

Bare Multi-Signature

The size of bare Multi-Signature (multisig) outputs depends on n, the size of the set of accepted keys. The overall size is made up of two components: a fixed 12-byte contribution comprising the eight-byte amount; a one-byte variable-length integer encoding the locking script’s size; and three bytes for the OP_m , OP_n , and OP_CHECKMULTISIG instructions that are part of the locking script. Additionally, there is a dynamic contribution of 34n bytes, for each of the public-key encodings in the locking script requires a one-byte variable-length integer to indicate the key’s size and the 33-byte key itself. The overall size estimate for m-of-n-multisig outputs is thus 12+34n bytes.

In the following, this analytic estimate is verified for 1-of-2 and 1-of-3 multisig outputs, which together amount for more than 98% of all multisig outputs. The estimate for the former is 80 bytes; for the latter it is 114 bytes. The empirical data in the figure below, which contains histograms of the sizes of all 1-of-2 and 1-of-3 multisig outputs as of block 637,302, supports these estimates: the bulk of 1-of-2 and 1-of-3 multisig outputs have a size of 80 and 112 bytes, respectively. In each case, there is a smaller number of outputs that are 32 bytes larger than the estimate. As before, these are artifacts that can be attributed to the early days of Bitcoin, where public keys were encoded using the uncompressed SEC format.

The size of multisig inputs depends on m, the number of signatures required to unlock the referenced output. The overall size is made up of two components: a fixed 42-byte contribution comprising the 32-byte hash, the 4-byte position, the 4-byte sequence number, one byte for the variable-length integer encoding the unlocking script’s length, and one byte for the OP_0 instruction that is part of the unlocking script. Additionally, there is a dynamic contribution of 72.5m bytes, for each of the signature encodings in the unlocking script includes a one-byte variable-length integer to indicate the signature size and signature itself, which, on average, has a size of 71.5 bytes. The estimate for the overall size of m-of-n-multisig inputs is thus 44+72.5m bytes.

As before, this analytic estimate is verified for 1-of-2 and 1-of-3 multisig variants. Since m=1 for both variants, they share the same estimate of 114.5 bytes. The empirical data in the figure below, which contains a histogram of the sizes of all 1-of-2 and 1-of-3 multisig outputs as of block 637,302, supports this estimate: as expected, the bulk of all 1-of-2 and 1-of-3 multisig outputs have a size of either 114 or 115 bytes.

Null Data

The size of Null-Data outputs depends on s, the size of the user’s payload included in the output. The overall output size is made up of two components: a fixed ten-byte contribution comprising the 8-byte amount, one byte for the variable-length integer encoding the unlocking script’s length, and one byte for the OP_RETURN instruction that is part of the locking script. Additionally, there is a dynamic contribution that includes the encoding of the length of the locking script, the encoding of the length of the user’s payload, and the actual payload. If the payload is smaller than 75 bytes, its length can be explicitly encoded in Bitcoin script and requires only one byte; if the payload is larger than 75 bytes, an additional OP_PUSHDATA1 instruction is required, increasing the total requirement to encode the length of the payload to two bytes. The overall estimate for Null-Data outputs is thus 11+s when including a payload with a size of up to 75 bytes, and 12+s when including a larger payload.

This analytic estimate is verified for 20- and 80-byte Null-Data outputs, which together amount for more than 90% of all Null-Data outputs. The estimate for the former is 31 bytes; for the latter it is 92 bytes. The empirical data in the figure below, which contains histograms of the sizes of all Null-Data outputs as of block 637,302, supports these estimates.

Pay-to-Script-Hash

Pay-to-Script-Hash (P2SH) outputs have a fixed size of 32 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and the 23-byte locking script.

This analytic estimate is corroborated by the empirical data in the figure below, which contains a histogram of all P2SH outputs as of block 637,302, and confirms that all P2SH outputs have a size of 32 bytes.

In contrast to fixed-size P2SH outputs, the size of P2SH inputs varies significantly depending on the type of redeem script included in the input. The most relevant redeem-script use cases are discussed in the following.

Pay-to-Script-Hash-Multi-Signature

The size of P2SH-multisig inputs depends on m, the number of signatures required to satisfy the redeem script; and n, the size of the set of accepted keys. The overall size of P2SH-multisig inputs is made up of two components: a fixed 40-byte contribution comprising the 32-byte hash, the 4-byte position, and the 4-byte sequence number; and a variable contribution including the size of the unlocking script and the encoding of the script’s size. The unlocking script, in turn, comprises two components: a redeem script, whose hash matches the hash in the referenced UTXO’s locking script, that is interpreted as locking script; and data to satisfy the redeem script.

The redeem script is identical to a bare multisig locking script and comprises: a fixed contribution of three bytes for the OP_m , OP_n , and OP_CHECKMULTISIG script instructions; and a dynamic contribution of 34n bytes, for each of the n encoded public keys in the redeem script contributes a one-byte variable-length integer to encode the keys size and the 33-byte key itself. The redeem script’s contribution is thus 3+34n bytes in total. The overhead of the Bitcoin script instruction(s) pushing the redeem script onto the stack depends on the redeem script’s size: if it is smaller than 75 bytes, its length can be explicitly encoded using a one-byte Bitcoin script instruction; if the redeem script is larger than 75 bytes, an additional OP_PUSHDATA1 instruction is required, increasing the contribution by one byte.

In addition, the unlocking script contains data to satisfy the redeem script. This data is identical to a bare multisig unlocking script and includes fixed a one-byte contribution for the OP_0 instruction; and a dynamic contribution of 72.5m bytes to encode m 71.5-byte ECDSA signatures and their lengths. The data’s contribution is thus 1+72.5m bytes.

The total size of a P2SH-multisig input is thus given by the sum of the fixed 40-byte contribution, the redeem script’s size of 3+34n bytes, the one- or two-byte overhead of pushing the redeem script onto the stack, the contribution of the data to satisfy the redeem script’s of 1+72.5m bytes, and the contribution of the variable-size integer to encode the unlocking script’s length.

This analytic estimate is verified for 2-of-2 and 2-of-3 P2SH-multisig inputs, which together amount for more than 90% of P2SH-multisig inputs. For the former, n=2, so the estimate for the redeem script’s size is 3+34n=71 bytes. Because the witness script is smaller than 75 bytes, the overhead of pushing it onto the stack is only one byte. Moreover, m=2, so the contribution of the data to satisfy the redeem script is 146 bytes. The unlocking script’s size is thus 218 bytes. Because the script is smaller than 253 bytes, the variable-length integer encoding its size requires only one byte. Together with the fixed contribution of 40 bytes, the estimate for a 2-of-2 P2SH-multisig input is thus 259 bytes.

This estimate is corroborated by empirical data shown in the histogram below, which contains a histogram of all 2-of-2 and 2-of-3 P2SH-multisig inputs as of block 637,302. Almost half of all 2-of-2 P2SH-multisig inputs have a size of 259 bytes. The remaining inputs are either one byte smaller or larger than that, a fact which can be explained by signatures being, on average, 71.5 bytes: absent the low-r optimization, there is a 50% probability of generating either a 71-byte or 72-byte signature; for two signatures, this implies a 25% chance of two 71-byte signatures (corresponding to inputs with a size of 258 bytes), a 50% chance of one 71-byte and a 72-byte signature (resulting in 259-byte inputs), and a 25% chance of two 72-byte signatures (leading to 260-byte inputs).

For 2-of-3 P2SH-multisig inputs n=3, so the estimate for the redeem script’s size is 3+34n=105 bytes. Because the witness script is larger than 75 bytes, the overhead of pushing it onto the stack is two bytes: one byte for the OP_PUSHDATA1 instruction, another byte encoding the size of the redeem script. Moreover, m=2, so contribution of the data to satisfy the redeem script is 146 bytes. The unlocking script’s size is thus 253 bytes. The script’s size in this instance is not smaller than 253 bytes, so the encoding of the unlocking script’s size with a variable-length integer requires three bytes.
Together with the fixed contribution of 40 bytes, the estimate for a 2-of-3 P2SH-multisig input is thus 296 bytes.

This estimate is also validated by empirical data shown in the histogram above: almost half of all 2-of-3 P2SH multisig inputs have a size of 296 bytes. As before, around 25% of the inputs have a size that is one byte larger than the estimate; again, this circumstance can be explained by the 25% chance of generating two 72-byte signatures compared to the estimate, which uses two times 71.5 bytes. Another 25% of inputs have a size that at 293 bytes is three bytes smaller than the estimate. The reason for this is that in case of two 71-byte signatures, the unlocking script’s size is only 252 bytes, which implies that its size can be encoded with a one-byte variable-length integer instead of a three-byte one. The combined reduction in size is thus tree bytes: a one-byte reduction stemming from the use of two 71-byte signatures instead of the estimate of two times 71.5 bytes; another two bytes because only one byte (instead of three) is required to encode the unlocking script’s size.

Pay-to-Script-Hash-Pay-to-Witness-Script-Hash-Multi-Signature

Pay-to-Script-Hash-Pay-to-Witness-Script-Hash-Multi-Signature (P2SH-P2WSH-multisig) inputs have a fixed size of 76 bytes: 40 bytes for referencing a UTXO and the sequence number, a one-byte variable-length integer to encode the unlocking script’s size, and a 35-byte unlocking script.

The analytic estimate is supported by empirical data, shown in the figure below. The histogram, which displays the size of all P2SH-P2WSH-multisig inputs as of block 637,302, indicates that all such inputs have a size of 76 bytes.

The size P2SH-P2WSH-multisig witnesses depends on m, the number of signatures required to satisfy the witness script; and n, the size of the set of accepted keys. The size of witnesses is entirely dynamic; contributions comprise: a witness script that is interpreted as locking script; data to satisfy the locking script; and variable-length integers indicating the size of each witness item as well as the number of overall items.

The witness script contains the same information as a P2SH-multisig redeem script, so it contributes the same 3+34n bytes. Since the witness script is a witness item, its length it encoded using a variable-length integer.

The data to unlock the witness script is similar to that used in P2SH-multisig inputs with the only difference that signatures are individual witness items whose length is encoded using a variable-length integer instead of being script data that is pushed onto the stack using Bitcoin script instructions. This, however, has no impact on the size: each of the m signatures contributes, on average, 71.5 bytes, plus one byte to encode its length using a variable-length integer. In addition, the data includes a variable-length integer indicating one item of zero length to push an empty item onto the stack (analogous to the OP_0 instruction used when the data is encoded in a Bitcoin script). The overall contribution of the data is thus the same 1+72.5m bytes as was the case for P2SH-multisig inputs.

The total witness size is thus given by the size of the variable-length integer indicating the number of witness items, the data’s contributions of 1+72.5m bytes, the witness script’s contribution of 3+34n bytes, and the size of the variable-length integer indicating the size of the witness script.

This analytic estimate is verified for 2-of-2 and 2-of-3 P2SH-P2WSH-multisig inputs, which combined amount for more than 90% of P2SH-P2WSH-multisig inputs. For the former, m=n=2, so the data’s and witness script’s contributions are 1+72.5m=146 bytes and 3+34n=71 bytes, respectively. Together with the two one-byte variable-length integers to indicate the number of witness items (three: two signatures and the witness script) and the length of the witness script, the overall estimate is 219 bytes.

For 2-of-3 P2SH-P2WSH-multisig inputs, m=2 and n=3, so the data’s and witness script’s contributions are 1+72.5m=146 bytes and 3+34n=105 bytes, respectively. Again, the two variable-length integers indicating the number of witness items and the length of the witness script contribute two bytes, so the overall estimate is 253 bytes.

These estimates are supported by the empirical data shown in the figure below, which contains a histogram of all 2-of-2 and 2-of-3 P2SH-P2WSH-multisig witnesses as of block 637,302. For both multisig variants, the peak of the distribution matches the estimate. As before, inputs that are one byte smaller or larger than the estimate can be explained by the 25% chances of creating either two 71-byte signatures or two 72-byte signatures instead of the estimate, which uses the average of two times 71.5 bytes.

Pay-to-Script-Hash-Pay-to-Witness-Public-Key-Hash

Pay-to-Script-Hash-Pay-to-Witness-Public-Key-Hash (P2SH-P2WPKH) inputs have a fixed size of 64 bytes: 40 bytes for referencing a UTXO and the sequence number, a one-byte variable-length integer to encode the unlocking script’s size, and a 23-byte unlocking script.

The analytic estimate is supported by empirical data, shown in the figure below. The histogram, which includes the sizes of all P2SH-P2WPKH inputs as of block 637,302, indicates that all such inputs have a size of 64 bytes.

The average size of P2SH-P2WPKH witnesses is about 107.5 bytes: a one-byte variable-length integer indicating the number of items in the witness (two: a signature and a public key); a 71.5-byte signature and a one-byte variable-length integer encoding its size; and a 33-byte public key and a one-byte variable-length integer encoding its size.

This estimate is corroborated by empirical data. The histogram shown in the figure below displays the sizes of all P2SH-P2WPKH witnesses as of block 637,302. The data indicates more than 60% of all P2SH-P2WPKH witnesses have a size of 107 bytes; the remaining 40% have a size of 108 bytes. The bias toward 107 bytes can be explained by the low-r optimization, which results in 71-byte signatures in comparison to the 71.5-byte average used by the estimate.

Pay-to-Witness-Public-Key-Hash

Pay-to-Witness-Public-Key-Hash (P2WPKH) outputs have fixed size of 31 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and a 22-byte locking script.

This analytic estimate is supported by the empirical data shown in the figure below, which contains a histogram of the sizes of all P2WPKH outputs as of block 637,302. As expected, all observed outputs have a size of 31 bytes.

P2WPKH inputs also have fixed size. The contributions of a 32-byte transaction id, a four-byte position, a one-byte variable-length integer, an empty unlocking script, and a four-byte sequence number result in a total size of 41 bytes.

Again, the estimate is corroborated by empirical data. The figure below contains a histogram of the sizes of all P2WPKH inputs as of block 637,302. The data indicates that all of them have a size of 41 bytes.

P2WPKH witnesses contain the same data as P2SH-P2WPKH witnesses: a one-byte variable-length integer indicating the number of items in the witness (two: a signature and a public key); a 71.5-byte signature and a one-byte variable-length integer encoding its size; and a 33-byte public key and a one-byte variable-length integer encoding its size. P2WPKH witnesses thus have the same 107.5-bytes estimate as P2SH-P2WPKH witnesses.

Again, the analytic estimate is supported by empirical data. The histogram shown in the figure below displays the sizes of all P2WPKH witnesses as of block 637,302. The data shows that the bulk of witnesses have a size of either 107 or 108 bytes. As was the case for P2SH-P2WPKH witnesses, the bias toward 107 bytes can be explained by the low-r optimization, which allows producing 71-byte signatures in comparison to the 71.5-byte average used for the estimate.

Pay-to-Witness-Script-Hash

Pay-to-Witness-Script-Hash (P2WSH) outputs have fixed size of 43 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and the 34-byte locking script.

This analytic estimate is supported by the empirical data shown in the figure below, which contains a histogram of the size of all P2WSH outputs as of block 637,302. As expected, all observed outputs have a size of 43 bytes.

P2WSH inputs also have fixed size. The contributions of a 32-byte transaction id, a 4-byte position, a one-byte variable-length integer, an empty unlocking script, and a 4-byte sequence number result in a total size of 41 bytes.

As before, the estimate is corroborated by empirical data. The figure below contains a histogram of the size of all P2WSH inputs as of block 637,302. The data indicates that all of them have a size of 41 bytes.

P2WSH witnesses contain the same data as P2SH-P2WSH witnesses. The size of a P2WSH witness is thus given by the following contributions: a variable-length integer indicating the number of witness items; 1+72.5m bytes of data to satisfy the witness script; the witness script, which contributes 3+34n bytes; and another variable-length integer indicating the size of the witness script.

In the following, the analytic estimate is verified for 1-of-1, 2-of-2, and 2-of-3 P2WSH-multisig witnesses, which together amount for more than 98% of all P2WSH-multisig transactions.

For 1-of-1 P2WSH-multisig, the witness script is 3+34n=37 bytes, so the variable-length integer encoding the witness script’s size requires only one byte. Moreover, the data to satisfy the witness script contributes 1+72.5m=73.5 bytes. The variable-length integer to encode the number of stack items contributes another byte. The total estimate is thus 112.5 bytes.

This estimate is supported by the empirical data shown in the figure below, which contains histograms of the sizes of all witnesses for the P2WSH-multisig variants under consideration. For 1-of-1 P2WSH-multisig, the observed sizes of 112 or 113 bytes match the analytic estimate.

For 2-of-2 P2WSH-multisig, m=2 and n=2. The witness script is thus 3+34n=71 bytes, and the variable-length integer encoding the witness script’s size requires only one byte. Moreover, the data to satisfy the witness script contributes 1+72.5m=146 bytes. The variable-length integer to encode the number of stack items contributes another byte. The total estimate is thus 219 bytes.

For 2-of-3 P2WSH-multisig, m=2 and n=3, so the data’s and witness script’s contributions are 1+72.5m=146 bytes and 3+34n=105 bytes, respectively. Again, the two variable-length integers indicating the number of witness items and the length of the witness script contribute two bytes, so the overall estimate is 253 bytes.

Both the 2-of-2 and 2-of-3 estimates are supported by the empirical data shown in the figure above. Note that, as before, in case of 2-of-3 P2WSH-multisig, the bias toward 252 bytes can be explained by the low-r optimization.

Pay-to-Taproot

Pay-to-Taproot (P2TR) outputs have fixed size of 43 bytes: eight bytes to encode the value, a one-byte variable-length integer encoding the locking script’s size, and the 34-byte locking script.

P2TR inputs also have fixed size. The contributions of a 32-byte transaction id, a 4-byte position, a one-byte variable-length integer, an empty unlocking script, and a 4-byte sequence number result in a total size of 41 bytes.

In case of key path, P2TR witnesses have a fixed size, too. The contributions of a one-byte variable-length integer indicating the number of witness items, another one-byte variable-length integer to indicate the length of a Schnorr signature, and a 64-byte Schnorr signature result in an estimate of 66 bytes for the total size of the witness.

In case of script path, P2TR witnesses have a variable size. Given the absence of empirical data, it is impossible to derive the sizes of common use cases. Moreover, absent empirical data, the previous analytic estimates cannot be verified.

Transaction format

So far, the sizes of different input, output, and witness types were discussed. To give estimates for transactions, additional data that is part of transactions needs to be taken into account.

In addition to inputs, outputs, and witnesses, transactions include: a four-byte version; in case any of a transaction’s inputs uses witness data, a one-byte Segregated Witness (SegWit) marker and one-byte SegWit version; two variable-length integers to indicate the number of inputs, outputs (the number of witnesses is identical to that of inputs, so two variable-length integers are sufficient); and a four-byte lock-time field.

Transaction-size estimates are then given by fixed eight-byte contribution given by the transaction’s version and lock time; the size of the variable-length integer indicating the number of inputs and the inputs themselves; the size of the variable-length integer indicating the number of outputs and the inputs themselves. In case of SegWit transactions, the size of the witnesses and the fixed two-byte contribution of the SegWit marker and flag must be considered as well.

Automated transaction-size estimates with libtxsize

libtxsize distills all previous findings into a library for automated transaction-size estimates. libtxsize is written in Python and includes simple Python interfaces to get estimates for input, output, and witnesses sizes, as well as estimates for arbitrary transactions. Moreover, it includes a command-line interface to play around with; estimating a transaction’s size is as simple as specifying the desired input and output types:

In addition to the overall transaction-size estimate, libtxsize also includes information of the different parts of the transaction, such as individual inputs, outputs, and witnesses, as well as transaction overhead. Moreover, libtxsize includes weight and virtual-size estimates in addition to size estimates.

Note that to make results more relevant, estimates assume 71-byte signature sizes based on the low-r optimization, which was introduced in 2018.

Results and Conclusion

The size of different input, output, and witness types were investigated using first-principles analysis. Based on the results of the analysis, estimates were established for all relevant use cases; moreover, all estimates (with the exception of Pay-to-Taproot) were validated using empirical data.

The following table summarizes these findings for quick reference. It includes input, output, and witness sizes for the most relevant use cases. Note that the estimates are based on an ECDSA-signature size of 71.5 bytes.

Moreover, libtxsize, a library that automates transaction-size estimates was presented. libtxsize represents the essence of the findings of this and previous investigations.

If you found the information in this article useful, feel free to contribute: 16pGpaoAhzoneLdRdxPSo9xAAPhzWnP2dA . If you have scientific, Bitcoin-related freelance work, let me know.

Самые быстрые криптовалюты с высоким TPS

В наш век покупок в один клик мы хотим получить все и сразу. Мы привыкли к практически мгновенному исполнению всего, начиная от цифровых товаров и заканчивая заказом физических товаров через Интернет. Криптовалютное пространство не является исключением. Инвесторы, разработчики и обычные пользователи считают более быстрые транзакции более желательными, поскольку они создают более приятный пользовательский опыт. В результате скорость является важным критерием для определения потенциала криптопроекта.

В этой статье мы рассмотрим метрику транзакций в секунду, как она влияет на скорость сети блокчейн, а также 11 самых быстрых блокчейнов.

Что такое TPS и как он связан со скоростью блокчейна?

TPS (или количество транзакций в секунду) – это количество транзакций, которые сеть блокчейн может провести за одну секунду. Он отражает скорость блокчейна, поскольку показывает, насколько масштабируема и быстра сеть. TPS также называют пропускной способностью.

Однако TPS – не единственный параметр, определяющий скорость блокчейна. Время завершения транзакции (время, необходимое для подтверждения неизменности транзакции) не менее важно. Вместе эти параметры характеризуют масштабируемость сети блокчейн, то есть способность сети обрабатывать все большее количество транзакций.

Масштабируемость является актуальной темой в блокчейне, поскольку недостаточная масштабируемость является значительным камнем преткновения на пути к более широкому внедрению технологии блокчейн.

Стремление к высокой скорости криптовалютных транзакций

Основной проблемой для новаторов блокчейна является одновременное поддержание высокой скорости транзакций, децентрализации и безопасности. Эту проблему соучредитель Ethereum Виталик Бутерин назвал “трилеммой блокчейна”.

Как эффективность сети блокчейн, так и ее общий оптимальный пользовательский опыт зависят от масштабируемости. Поэтому большинство последних проектов стремятся внедрять различные инновационные системы для увеличения пропускной способности сети и, таким образом, ставят масштабируемость выше децентрализации и безопасности. Тем не менее, несколько блокчейн-проектов предприняли похвальные попытки решить трилемму блокчейна.

Какие криптовалюты самые быстрые?

Разработчики блокчейна всегда боролись за последовательное достижение трио децентрализации, безопасности и масштабируемости. Однако масштабируемость является наиболее желанной, поскольку она является ключом к массовому внедрению технологии. Учитывая это, вот одиннадцать блокчейнов с одним из самых высоких показателей TPS.

Solana (SOL)

Блокчейн Solana (SOL) существует с 2017 года и является одной из самых быстрых цепочек со скоростью транзакций 3 000 TPS (теоретически до 710 000). Высокомасштабируемый блокчейн Solana достигает такой впечатляющей скорости с помощью гибридного механизма консенсуса с доказательством истории (PoH)/доказательством ставки (PoS).

Еще более впечатляющим является время завершения блока в Solana – от 21 до 46 секунд. Время окончательности описывает время, которое требуется блокчейн-транзакции для подтверждения ее неизменности (то есть, она не может быть изменена). Время завершенности так же важно, как и пропускная способность транзакций, для определения скорости транзакций и, следовательно, масштабируемости сети. Благодаря высокой пропускной способности, Solana имеет низкие комиссии и еще более низкую перегрузку сети, что делает его привлекательным протоколом для запуска DApps, игр и, в последнее время, NFT (неиграбельных токенов).

Ripple (XRP)

Ripple (XRP), основанная на блокчейне альтернатива трансграничным платежным системам, таким как SWIFT (Общество всемирных межбанковских финансовых телекоммуникаций), может похвастаться скоростью транзакций в 1 500 TPS, которая предположительно может быть увеличена до 50 000 TPS.

Разработанная для того, чтобы соперничать со скоростью транзакций традиционных трансграничных платежных систем, Ripple взимает $0,0003 за транзакцию (по сравнению с $15-$20 за транзакцию SWIFT), а на завершение операции уходит от 3 до 5 секунд, что повышает общую эффективность сети. XRP опирается на сеть доверенных узлов, которая требует 80% консенсуса, прежде чем транзакция будет обработана и подтверждена. Этот уникальный метод поставил под сомнение ее децентрализацию.
Однако благодаря высокой скорости и низким комиссиям Ripple уже принята многими банками в мире для облегчения международных денежных переводов и перечислений.

Ethereum 2.0

Ethereum 2.0 (также известный как Serenity), когда он наконец-то будет запущен, должен стать одной из самых быстрых криптовалют в мире с TPS в 100 000, что гораздо больше, чем нынешние 12-15 TPS. В настоящее время Ethereum 2.0 находится в стадии разработки и, по прогнозам, будет запущен в начале 2023 года.

Текущая цель заключается в том, чтобы сделать Ethereum быстрее, дешевле и чище. Ethereum перейдет от консенсуса proof-of-work (PoW), на котором он сейчас построен, к высокомасштабируемому proof-of-stake (PoS). Ethereum 2.0 также призван обойти проблемы масштабируемости, децентрализации и безопасности за счет использования шардинга. Одним словом, Eth2, по прогнозам, внесет важные изменения в нынешнюю экосистему Ethereum, сделав ее более масштабируемой, безопасной и устойчивой.

Algorand (ALGO)

Блокчейн Algorand – это безопасная и масштабируемая сеть, созданная для поддержки различных приложений. Запущенная в 2019 году, Algorand известна своей высокой пропускной способностью, составляющей в среднем 1 300 TPS при заявленной потенциальной мощности в 3 000 TPS. Время завершения блока также впечатляет: проверка транзакций завершается примерно за 5 секунд.

Algorand использует чистый механизм консенсуса proof-of-stake (PPoS), случайным образом выбирая и вознаграждая майнеров, подтверждающих транзакции, чтобы обеспечить беспристрастную среду. Этот механизм позволяет Algorand достичь децентрализации, сохраняя при этом высокую скорость TPS.

Algorand обладает пропускной способностью и масштабируемостью, необходимыми для поддержки широкого спектра сценариев использования в глобальном масштабе. Многие разработчики DApp и DeFi обращаются к этой сети, чтобы избежать высоких сборов и перегруженности Ethereum.

Fantom (FTM)

Fantom – одна из самых быстрых сетей в этом списке. В дополнение к скоростному TPS в 25 000, протокол имеет время завершения блока около 1 секунды. Для перспективы сравните это время с 21-46 секундами у Solana и 60 секундами у Ethereum.

Сеть Fantom, поддерживающая смарт-цепочки, использует направленный ациклический граф (DAG) – технологию распределенной бухгалтерской книги, состоящей из компьютерной сети, которая параллельно выполняет транзакции. Для подтверждения транзакций каждый компьютер в DAG “сплетничает” о своих транзакциях случайным соседним компьютерам, которые повторяют аналогичные действия, мгновенно распространяя транзакцию по всей сети. Эта система отвечает за высокую пропускную способность сети Fantom и практически неограниченную масштабируемость.

Fantom также использует виртуальную машину Ethereum (EVM), что делает ее совместимой с Ethereum. В результате разработчикам Ethereum будет легко развернуть DApps в сети Fantom. Благодаря своей молниеносной скорости и нескольким программам поощрения, ориентированным на разработчиков, Fantom, безусловно, имеет блестящие перспективы в качестве платформы для DApps.

Cosmos (ATOM)

Сеть Cosmos (ATOM), разработанная с акцентом на персонализацию и совместимость, имеет завидную репутацию Интернета блокчейн. Она может обрабатывать более 10 000 транзакций в секунду и имеет среднее время завершения 2-3 секунды.

Cosmos реализует консенсус (PoS) и опирается на надежный технологический стек, состоящий из:

  • Tendermint: Механизм консенсуса, который позволяет разработчикам создавать масштабируемую, быструю и безопасную сеть блокчейн. (IBC): Система, которая соединяет разрозненные блокчейны.
  • Cosmos SDK: Популярный фреймворк для создания DApps поверх блокчейна на базе Tendermint.

Благодаря высокой масштабируемости, совместимости и возможности создания смарт-контрактов, Cosmos стал популярен среди разработчиков, создающих мощные межцепочечные DApps. К числу наиболее популярных относятся Anchor, Chainweaver, Klever и Flare.

Avalanche (AVAX)

Avalanche Network, один из самых быстрых блокчейнов, поддерживает смарт-контракты и имеет впечатляющую производительность в 4 500 TPS.
4 500 TPS, а время завершения блока составляет 1-2 секунды.

Уникальный подход Avalanche к решению трилеммы блокчейна заключается в использовании механизма PoS и уникальной системы из трех блокчейнов в рамках своей экосистемы. Каждый блокчейн ориентирован на определенную цель. Exchange Chain – это биржевой блокчейн, позволяющий торговать активами; Contacts Chain позволяет разработчикам создавать децентрализованные приложения; Platform Chain отслеживает валидаторов, которые управляют подсетями Avalanche.

Благодаря высокой пропускной способности и низким комиссионным, цель Avalanche – создать простой и единый глобальный рынок для торговли активами без трения – в значительной степени удалась. Поэтому прогнозируется, что многоцепочечный проект станет ведущим блокчейном для финансовых услуг в экономике веб 3.0.

Cardano (ADA)

Скорость транзакций составляет 250 TPS, а время завершения – 5-10 минут. Возможно, скорость транзакций Cardano и не сравнится с некоторыми другими в этом списке, но она не уступает им в плане безопасности и вовлеченности сообщества. Cardano (ADA) – это децентрализованный блокчейн с открытым исходным кодом, созданный для применения смарт-контрактов, таких как приложения DeFi, игры, криптовалютные токены и многое другое.

Cardano использует Ouroboros, уникальный, энергоэффективный консенсус PoS. Сеть случайным образом выбирает валидаторов пропорционально их ставкам для получения возможности создавать новые блоки. Цепочка Cardano состоит из двух уровней – расчетного уровня Cardano (CSL) и вычислительного уровня Cardano (CCL) – для обеспечения масштабируемости.

Экосистема Cardano содержит широкий спектр приложений DeFi и NFT, включая SundaeSwap, децентрализованную биржу, и MELD, протокол кредитования без доверия.

В настоящее время Cardano разрабатывает решение второго уровня, которое позволит увеличить пропускную способность до примерно

1 000 TPS и сократить время завершения до менее чем одной секунды. Эта модернизация, когда она будет реализована, поставит Cardano в один ряд с самыми масштабируемыми блокчейнами.

EOS.IO (EOS)

EOS – это сеть на основе блокчейна, оптимизированная как платформа для DApps. Следовательно, она обладает высокой пропускной способностью в 4 000 TPS, что позволяет обслуживать огромный объем транзакций. Но бывает и лучше: Транзакции EOS завершаются за 2-3 секунды, что делает EOS.IO одним из самых быстрых блокчейнов.

Для достижения такой скорости, как в Формуле-1, EOS использует делегированное доказательство ставки (DPoS) консенсус, который предполагает, что проверяющие (называемые свидетелями) приходят к консенсусу относительно следующего проверяющего для проверки транзакции. Сила голоса каждого свидетеля пропорциональна его ставке. Однако эта уникальная система голосования привела к обвинениям в централизации, поскольку несколько производителей блоков обладают большинством голосов.

Благодаря высокой масштабируемости, низкой задержке и бесчувственным транзакциям, цепочка EOS станет будущей платформой для реализации инициатив Веб 3.0. Она предлагает благодатное пространство для растущей сети DApps и сервисов, таких как pEOS, Upland, EOS Dynasty, Scatter и Newdex.

Polygon (MATIC)

Polygon (MATIC) – это блокчейн, который стремится масштабировать сеть Ethereum, поддерживая множество решений для масштабирования, включая решения второго уровня и сайдчейн. Он может похвастаться высокой пропускной способностью в 7 000 TPS (теоретически до 65 000) и временем завершения работы в 2-3 секунды. Polygon обеспечивает поддержку безопасности для других блокчейнов и связывает различные цепи со своей экосистемой, одновременно обрабатывая связь между участвующими цепями Polygon и цепями Ethereum. Polygon предлагает платформу для работы приложений Ethereum DApps в системе связанных блокчейнов, сохраняя при этом сетевую безопасность Ethereum и другие преимущества цепочки первого уровня.

Благодаря сверхбыстрой скорости и низким тарифам Polygon привлекает разработчиков, которых раздражает высокая плата за газ и низкая пропускная способность Ethereum. Все большее число известных игровых платформ, децентрализованных бирж и приложений DeFi используют сеть Polygon.

Bitgert (BRISE)

Bitgert был запущен 14 февраля 2022 года, что делает его самым новым проектом в этом списке и, возможно, самым быстрым. Bitgert обрабатывает колоссальные 100 000 транзакций в секунду, а время завершения блока составляет 2 секунды. В сочетании с такой невероятной скоростью, комиссия за транзакции на Bitgert ничтожно мала и составляет в среднем $0,00000001.

Bitgert создана на основе протокола Binance Smart Chain (BSC) и использует консенсус на основе доказательства полномочий (PoA), применяемый в BSC. Высокая пропускная способность, достигнутая Bitgert, обусловлена этим механизмом консенсуса, который позволяет валидаторам делать ставку не на монеты, а на свою репутацию.

Без сомнения, Bitgert – это следующее большое событие в криптоиндустрии. Проект находится на пути к

экспоненциальный рост благодаря практически нулевым комиссиям за газ и молниеносным транзакциям. С момента своего недавнего запуска он уже принимает множество проектов в сфере NFT, DeFi, metaverse и DApp.

Имеет ли скорость блокчейна значение?

Скорость имеет первостепенное значение в эпоху мгновенного удовлетворения и короткого периода внимания, особенно в финансовых операциях. Однако последние события в криптовалютном пространстве показали, что децентрализация и безопасность в равной степени жизненно важны.

В качестве примера можно привести серию сбоев, с которыми столкнулась сеть Solana.

Последний из них произошел 1 мая 2022 года. Валидаторы сети Solana не могли создавать новые блоки более четырех часов, и приложения на блокчейне Solana перешли в автономный режим. Как это произошло?

С пропускной способностью 50 000 TPS и средней стоимостью $0,00025 за транзакцию, разработчики NFT и DeFi устремились к блокчейну Solana. В сети наблюдался большой трафик, вызванный попытками ботов торговать NFT, которые, в свою очередь, перегрузили узлы сети. Причиной одного из предыдущих сбоев также была названа “ошибка”. Эти инциденты продемонстрировали негативные последствия компромиссного решения, принятого в сети, когда в обмен на скорость жертвуют безопасностью и стабильностью.

Другой инцидент, произошедший в сети EOSIO, также подчеркивает трудности трилеммы блокчейна. EOS заморозила семь счетов по подозрению в возможном воровстве. Однако это действие было встречено резкой критикой, поскольку решение было принято всего 21 избранным производителем блоков, что ставит под сомнение децентрализацию сети.

Хотя скорость транзакций важна, безопасность и децентрализация не менее важны. В конце концов, именно на них в первую очередь основывается развитие технологии блокчейн.

Скорость транзакций является важным показателем для широкого использования и принятия технологии блокчейн. Перечисленные выше блокчейны продемонстрировали значительную способность к масштабированию, что является важным требованием к блокчейнам будущего. Однако блокчейн, который будет править Веб 3.0, должен поддерживать разумную скорость транзакций без ущерба для безопасности и децентрализации.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *