Описание Casper Network
О монете
CasperLabs представляет собой децентрализованную вычислительную платформу, основанную на алгоритме консенсуса Proof-of-Stake. Для того чтобы эта система работала, требуется единица стоимости, потому что пользователи должны платить за вычисления, а валидаторы должны иметь долю для привязки.
Генерация и распространение токенов
Система блокчейн должна иметь запас токенов, доступных для оплаты вычислений и вознаграждения валидаторов за обработку транзакций в сети. Были предприняты большие усилия для того, чтобы ни одно физическое или юридическое лицо не приобрело 1% + токенов с начала запуска проекта. Помимо первоначального предложения, система будет иметь низкий уровень инфляции, результаты которого будут выплачиваться валидаторам в форме сеньоража. Количество токенов, используемых в качестве основы для расчета сеньоража, составляет 10 миллиардов.
Делимость токенов
Обычно «токен» делится на некоторое количество частей. Например, эфир делится на 10181018 частей (называемых Wei). Чтобы избежать ошибки округления, важно всегда представлять баланс токенов внутри системы в виде количества неделимых частей. Каждый CSPR делится на 109109 частей.
Минтинг и кошельки
Минтинг представляет собой контракт, по которому можно производить новые кристаллы определенного типа. Допускается использование нескольких типов кристаллов (для каждого из которых будет свой собственный минтинг), потому планируется существование большой экосистемы различных токенов, подобных токенам ERC20 в Ethereum. CasperLabs запустит специфический минтинг и будет управлять служебным токеном Casper (CSPR),который используется для оплаты вычислений и подключения к сети. Минтинг также поддерживает баланс для своего типа кристалла. Каждый баланс связан с URef, который действует как своего рода ключ, инструктирующий минтинг на выполнение действий с этим балансом (например, передавать частицы). URef - это ссылка на внешний кошелек.
Права доступа модели разрешений URefs определяют, какие действия разрешено выполнять при использовании URef, связанного с кошельком.
Поскольку все URef не поддаются подделке, единственный способ взаимодействовать с кошельком - предоставить URef с соответствующими правами доступа, которые должны быть предоставлены текущему контексту действительным способом.
Основные параметры глобального состояния отображаются на более стандартные денежные операции в соответствии с таблицей ниже:
| Действия обшего состояния | Финансовое действие |
| Добавить | Депозит ( например, отправить в...) |
| Записать | Вывод ( например, вывести с...) |
| Читать | Проверка баланса |
Интерфейс контракта минтинга
Действительный контракт минтинга предоставляет следующие методы
• передача (источник: URef, цель: URef, количество: Motes) -> TransferResult
источник должен иметь как минимум права доступа для записи, целевой объект должен иметь как минимум права доступа для добавления.
TransferResult может быть подтверждением успеха или ошибкой в случае неверного источника, кошелька получателя или недостаточного баланса в исходном кошельке
• минтинг(количество: кристаллы) -> MintResult
MintResult либо выдает созданный URef (с правами полного доступа), баланс которого теперь равен заданной сумме; или ошибку из-за недопустимости минтинга новых кристаллов
В системе минтинга CasperLabs только системная учетная запись может вызывать mint, и у нее нет закрытого ключа для создания действительных криптографических подписей, что означает, что только само программное обеспечение может выполнять контракты в контексте системной учетной записи.
• create () -> URef
вспомогательная функция для минтинга (0), которая не может дать сбой, потому что всегда можно создать пустой кошелек
• баланс (кошелек: URef) -> Опция <Motes>
Кошелек должен иметь как минимум права на чтение
BalanceResult либо возвращает количество кристаллов в кошельке, либо ничего, если URef недействителен.
Использование кошелька URefs
Передавать URef кошелька с разрешениями на запись в любой контракт опасно. Злонамеренный контракт может использовать этот доступ для получения большего количества токенов, чем было предназначено, или для передачи этого URef другому контракту, для которого не предназначался такой доступ. Поэтому, если для контракта требуется кошелек с разрешениями на запись, рекомендуется всегда использовать «платежный кошелек», который представляет собой кошелек, используемый для этой отдельной транзакции, и ничего больше. Это гарантирует, что даже если этот URef окажется скомпрометированным, он не будет содержать больше средств, чем пользователь намеревался предоставить.
пусть main_purse = contract_api :: main_purse ();
пусть payment_purse = contract_api :: create_purse ();
match contract_api :: transfer_purse_to_purse (main_purse, payment_purse, payment_amount) {TransferResult :: Success => contract_api :: call_contract (contract_to_pay, payment_purse),
_ => contract_api :: revert (1),}
Чтобы избежать этого неудобства, для разработчиков приложений, намеревающихся принимать платежи в цепочке, лучше сделать общедоступной версию своего кошелька URef с правами доступа на чтение. Это позволяет клиентам производить оплату переводом, используя свой собственный кошелек, при этом ни одна из сторон не предоставляет доступ на запись к любому кошельку.
Кошельки и аккаунты
У каждой учетной записи в системе CasperLabs есть кошелек, связанный с минтингом системы CasperLabs, который называется «основным кошельком» учетной записи. Однако из соображений безопасности URef основного кошелька доступен только для кода, работающего в контексте этой учетной записи (то есть только в коде платежа или сеанса). Поэтому метод перевода минтинга, который принимает URef, не самый удобный для использования при переводе между основными кошельками аккаунта. По этой причине CasperLabs предоставляет функцию transfer_to_account, которая принимает открытый ключ, используемый для получения идентификационного ключа учетной записи. Эта функция использует функцию передачи минтинга с основным кошельком текущего счета в качестве источника и основным кошельком учетной записи с предоставленным ключом в качестве цели. Функция transfer_from_purse_to_account аналогична, но в качестве источника использует данный кошелек, а не основной кошелек текущего аккаунта.
Структура блока
Блок представляет собой основную структура данных, с помощью которой информация о состоянии системы CasperLabs передается между узлами сети.
Далее краткое описание этой структуры данных.
Определение Protobuf
Сообщения между узлами передаются с помощью буферов протокола Google.
Поля данных
Блок состоит из следующего:
block_hash
header
body
signature
block_hash
Block_hash - это хэш заголовка blake2b256
Заголовок
Заголовок блока содержит следующие поля:
• parent_hashes
список block_hash, указывающий родительский блок
Обоснования
список block_hash, дающий обоснование блока
• сводку глобального состояния, включая корневой хэш дерева глобального состояния перед выполнением развертываний в этом блоке (pre_state_hash)
корневой хэш дерева глобального состояния после выполнения развертываний в этом блоке (post_state_hash)
Список действующих валидаторов и их доли
• хэш blake2b256 тела блока
• время создания блока
• версия протокола, с которой выполнялся блок
• количество развертываний в блоке
• удобочитаемое имя, соответствующее этому экземпляру системы CasperLabs (chain_id)
• открытый ключ валидатора, создавшего этот блок
• индикатор того, предназначено ли это сообщение как истинный блок или просто бюллетень
Тело
Тело блока содержит список развертываний, обработанных как часть этого блока. Обработанное развертывание содержит следующую информацию:
• копия сообщения о развертывании, которое было выполнено (см. Семантику выполнения для получения дополнительной информации о развертываниях и способах их выполнения)
• количество потраченного газа при его исполнении
• флаг, указывающий, возникла ли ошибка при развертывании
• строка для сообщения об ошибке (если применимо)
Подпись
Подпись блока криптографически доказывает, что блок был создан валидатором, открытый ключ которого содержится в заголовке. Подпись создается с использованием указанного алгоритма (в настоящее время поддерживается только Ed25519) и подписывается с помощью block_hash, поэтому она уникальна для этого блока.
Контракты
Контракты представляют собой особый тип значения, поскольку они содержат логику цепочки приложений, работающих в системе CasperLabs. Контракт содержит следующие данные:
• модуль wasm
• набор именованных ключей
• версия протокола
Модуль wasm должен содержать функцию с именем call, которая не принимает аргументов и не возвращает значений. Это основная точка входа в договор. Более того, модуль может импортировать любые функции, поддерживаемые средой исполнения CasperLabs.
Хотя сигнатура функции вызова не имеет аргументов и возвращаемого значения, в теле функции вызова функция времени выполнения get_ named_arg может использоваться для приема аргументов (по порядковому номеру), а функция времени выполнения ret может использоваться для возврата одного CLValue вызывающей стороне.
Именованные ключи используются для присвоения удобочитаемых имен ключам в глобальном состоянии, которые важны для контракта. Например, хэш-ключ другого контракта, который он часто вызывает, может храниться под значащим именем. Он также используется для хранения URef, которые известны контракту.
Версия протокола указывает, с какой версией протокола CasperLabs этот контракт был скомпилирован для совместимости. Контракты, несовместимые с активной версией основного протокола, не будут выполняться ни одним узлом в сети CasperLabs.
Комментарии
Комментарии для сайта Cackle