Аренда

Учетные записи в Solana могут иметь контролируемое владельцем состояние (Account::data), которое отделено от баланса учетной записи (Account::lamports). Поскольку валидаторы в сети должны поддерживать рабочую копию этого состояния в памяти, сеть взимает плату за потребление этого ресурса, основанную на времени и пространстве, также известную как рента.

Двухуровневый режим аренды

Счета, которые поддерживают минимальный баланс, эквивалентный 2 годам арендных платежей, освобождаются. 2 года взяты из того факта, что стоимость оборудования падает на 50% каждые 2 года, и в результате сходимости из-за того, что они представляют собой геометрический ряд. Со счетов, баланс которых падает ниже этого порога, взимается арендная плата по ставке, указанной в генезисе, в лэмпортах за байт-год. Сеть взимает арендную плату за каждую эпоху в кредит на следующую эпоху, а Account::rent_epoch отслеживает, когда в следующий раз арендная плата должна быть собрана со счета.

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

Сроки сбора арендной платы

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

Напротив, сбор арендной платы не применяется к учетным записям, которые напрямую манипулируются любым из процессов бухгалтерского учета на уровне протокола, включая:

• Само распределение сбора ренты (в противном случае это может привести к рекурсивной обработке сбора ренты)
• Распределение вознаграждений за стекинг в начале каждой эпохи (чтобы уменьшить количество обработки в начале новой эпохи)
• Распределение комиссии за транзакцию в конце каждого слота

Даже если эти процессы выходят за рамки сбора ренты, все управляемые учетные записи в конечном итоге будут обрабатываться механизмом (2).

Фактическая обработка сбора арендной платы

Арендная плата взимается за время, равное одной эпохе, и учетные записи имеют Account::rent_epoch из current_epoch или current_epoch + 1 в зависимости от режима аренды.

Если учетная запись находится в режиме исключения, Account::rent_epoch просто обновляется до current_epoch.

Если учетная запись не освобождена, разница между следующей эпохой и Account::rent_epoch используется для расчета суммы арендной платы, причитающейся с этой учетной записи (через Rent::due()). Любые дробные лампы вычисления усекаются. Арендная плата вычитается из Account::lamports, а Account::rent_epoch обновляется до current_epoch + 1 (= следующая эпоха). Если сумма причитающейся арендной платы меньше одного лампорта, в счет не вносятся изменения.

Аккаунты, баланс которых недостаточен для оплаты арендной платы, просто не загружаются.

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

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

Рекомендации по дизайну

Обоснование текущего дизайна

В соответствии с предыдущим дизайном НЕ возможно иметь учетные записи, которые задерживаются, никогда не трогаются и никогда не нужно платить арендную плату. Учетные записи всегда платят арендную плату ровно один раз за каждую эпоху, за исключением учетных записей без арендной платы, sysvar и исполняемых учетных записей.

Это предполагаемый выбор дизайна. В противном случае можно было бы инициировать несанкционированный сбор арендной платы с помощью инструкции «Noop» любым, кто может несправедливо получить прибыль от арендной платы (лидер на данный момент) или сохранить арендную плату с учетом ожидаемых колебаний стоимости аренды.

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

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

Специальная коллекция

Рассматривался сбор арендной платы по мере необходимости \ (т. е. всякий раз, когда учетные записи загружались / открывались ). Проблемы с таким подходом:

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

• желателен механизм "ходить в кусты" (т.е. искать аккаунты, которые должны платить арендную плату), чтобы аккаунты, которые загружаются нечасто, получали халяву

Системная инструкция по сбору арендной платы

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

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