В нашей серии статей в блоге «Криптография в Sui» рассказывается о технологиях, обеспечивающих безопасность транзакций и удобство использования в сети Sui. Эта серия помогает разработчикам понять инфраструктуру безопасности Sui и то, как разрабатывать безопасные децентрализованные приложения.
Sui следует спецификациям кошелька, широко принятым в криптовалютной индустрии, таким какБИП-32(и его вариант,СЛИП-0010),БИП-44, а такжеБИП-39. Эти спецификации стали обычным явлением в криптовалютной индустрии как средство для пользователей управлять ключами учетных записей.
В настоящее время Sui принимает подписанные транзакции с использованием Ed25519 или ECDSA Secp256k1. В Sui Wallet и SDK мы предоставляем гибкий интерфейс для подписи транзакций с различными схемами подписи.
Давайте подробнее рассмотрим, как именно мы применяем эти спецификации.
Схема получения ключей
Sui использует BIP-32 для управления кошельками, которые поддерживают схему подписи ECDSA Secp256k1.
BIP-32 определяет иерархическую детерминированную структуру кошелька для логического связывания набора ключей. Группировка ключей таким образом снижает затраты на отслеживание большого количества закрытых ключей для пользователя. Этот метод также позволяет хранителям выдавать отдельные управляемые адреса для каждой учетной записи пользователя под одним источником контроля.
Использование BIP-32 отделяет получение закрытого ключа от получения открытого ключа, позволяя использовать кошелек только для просмотра, когда можно получить цепочку открытых ключей и их адресов, в то время как закрытый ключ может храниться в автономном режиме для подписи.
Sui использует SLIP-0010 для управления кошельками, поддерживающими схему подписи Ed25519 (EdDSA).
Мы используем SLIP-0010, потому что BIP-32 изначально был разработан для ECDSA с группой простого порядка, тогда как кривая Ed25519 основана на групповом порядке h × ℓ , где h — малый кофактор, а ℓ — 252-кратный коэффициент. немного премьер. Это сложная техническая деталь, но стандарт подписи Ed25519 применяет фиксацию битов как к младшим, так и к старшим битам закрытого ключа, что делает некоторые режимы BIP-32 несовместимыми с Ed25519. В результате SLIP-0010 предписывает запретить получение нового открытого ключа из открытого ключа существующего пользователя. SLIP-0010 поддерживает только так называемый «защищенный» закрытый родительский ключ для получения закрытого дочернего ключа.
Путь получения ключа
В то время как BIP-32 определяет уровни кошельков в иерархической структуре, BIP-44 далее определяет пять уровней пути вывода с их точными значениями: m/цель/тип_монеты/учетная запись/смена/индекс_адреса . В этой структуре косые черты обозначают новые уровни или дочерние элементы в иерархии.
Целевой уровень обычно устанавливается равным 44, что соответствует номеру BIP. Однако в Sui уровень цели различает разные схемы подписи: 44 устанавливается для Ed25519 и 54 для ECDSA Secp256k1. Хотя нестандартно устанавливать для уровня назначения значение, отличное от 44, обычно используется поле назначения для различения различных схем подписи. Например, BIP-49 и BIP-84 используются для идентификации типов скриптов в биткойнах. Мы выбрали 54 для обозначения ECDSA Secp256k1, потому что не существует существующего BIP ниже 54, чтобы избежать путаницы с любым стандартом Биткойн.
Значение coin_type управляется репозиторием всех других криптовалют. Обе схемы подписи используют Суи.зарегистрирован coin_type , 784 (SUI на клавиатуре телефона).
Уровень account_index обычно используется для логического разделения учетных записей пользователей и создания определенных категорий учетных записей. Некоторые распространенные варианты использования включают в себя:
- Хранители управляют несколькими учетными записями пользователей.
- Пользователи назначают учетные записи для определенных целей, таких как пожертвования, сбережения и расходы.
Для поддержки нескольких учетных записей мы рекомендуем увеличивать уровень account_index, начиная с нуля.
это общепринятый что, в то время как валюты на основе счета определяют только первые три уровня , Валюты на основе UTXO добавить определения уровня изменений и адресов. Поскольку объектно-ориентированная модель данных Sui не основана ни на UTXO, ни на учетных записях (на самом деле она сочетает в себе и то, и другое), для максимальной совместимости в ней используются все пять уровней.
Обобщить:
Форма пути деривации | Заметки | |
Эд25519 | m/44'/784'/{аккаунт}'/{изменить}'/{адрес}' | Каждый уровень пути вывода усилен. |
ECDSA Secp256k1 | м/54'/784'/{аккаунт}'/{изменить}/{адрес} | Первые три уровня усилены. |
Поддержка Mnemonics
После того, как мы определили детерминированный способ получения главного ключа из начального числа, вводится BIP-39, чтобы сделать начальное число более удобочитаемым и запоминающимся с помощью мнемоники. Sui принимает 12, 15, 18, 21 и 24 слова из BIP-39.список слов это правильно подсчитанная контрольная сумма, соответствующая 128, 160, 192, 224 и 256 битам энтропии.
Управление ключами в Sui
Sui поддерживает генерацию пары ключей и связанную с ними мнемонику через свой SDK машинописного текста и интерфейс командной строки (CLI). SDK предоставляет дополнительные функции, включая подписание транзакций и интеграцию RPC.
Здесь мы демонстрируем, как:
- Получить пару ключей из мнемоники
- Получить его адрес
- Используйте его для подписи сериализованной типизированной транзакции (или любых данных)
- Выполнить против поставщика RPC
Typescript SDK
import { Ed25519Keypair, JsonRpcProvider, RawSigner } from '@mysten/sui.js';
const TEST_MNEMONICS = 'a 12-24 word mnemonics strings separated by space, from the wordlist';
// Create a keypair under Ed25519 scheme.
const keypair_ed25519 = Ed25519Keypair.deriveKeypair(TEST_MNEMONICS, "m/44'/784'/0'/0'/0'");
// Create a keypair under ECDSA secp256k1 scheme.
const keypair_secp256k1 = Secp256k1Keypair.deriveKeypair(TEST_MNEMONICS, "m/54'/784'/0'/0/0");
// Create a signer with the keypair with a provider.
const signer = new RawSigner(
keypair_ed25519, // or use keypair_secp256k1 for ECDSA secp256k1
new JsonRpcProvider('<https://gateway.devnet.sui.io:443>')
);
// Get the address.
const address = signer.getAddress();
console.log('address', address);
// Sign some random data.
const signData = new Base64DataBuffer(
new TextEncoder().encode('hello world')
);
const { signature, pubKey } = await signer.signData(signData)
console.log('signature', signature);
// Sign a typed data, i.e. a transfer object.
const transferTxn = await signer.transferObject({
objectId: '0x5015b016ab570df14c87649eda918e09e5cc61e0',
gasBudget: 1000,
recipient: '0xd84058cb73bdeabe123b56632713dcd65e1a6c92',
});
console.log('transferTxn', transferTxn);
Интерфейс командной строки
# Import mnemonics to sui.keystore with a scheme and a derivation path.
sui keytool import "SOME_MNEMONICS" ed25519 "m/44'/784'/0'/0'/0'"
2022-09-13T20:34:31.672453Z INFO sui::keytool: Key imported for address [SOME_ADDRESS]
sui keytool import "SOME_MNEMONICS" secp256k1 "m/54'/784'/0'/0/1"
2022-09-13T20:37:06.849647Z INFO sui::keytool: Key imported for address [SOME_ADDRESS]
# Generate random mnemonics and save to sui.keystore with a scheme and a derivation path.
sui client new-address ed25519 "m/54'/784'/0'/0'/1'"
Created new keypair for address with scheme Secp256k1: [SOME_ADDRESS]
Secret Recovery Phrase : [SOME_MNEMONICS]
sui client new-address secp256k1 "m/54'/784'/0'/0/1"
Created new keypair for address with scheme Secp256k1: [SOME_ADDRESS]
Secret Recovery Phrase : [SOME_MNEMONICS]
# Set the generated address to active in keystore.
sui client switch --address 0x8e2591958b19311ece3d748852f4693908be8b3c
# Get some gas objects.
sui client gas --address 0x8e2591958b19311ece3d748852f4693908be8b3c
Object ID | Gas Value
----------------------------------------------------------------------
0xba561fb82aa38075be60c0fad30e0c6b615c0f2e | 10000000
# Transfer an object to another address, signed with the active address in keystore. Success!
sui client transfer --gas-budget 1000 --to 0x1f7633037b5e185e162f51fca142fb6e8ebe50df --object-id 0xba561fb82aa38075be60c0fad30e0c6b615c0f2e
Transfer confirmed after 494589 us
----- Certificate ----
Transaction Hash: f4ntyDJrO7HfAiZtit1zprhqftyOj5nvpo+WitB5IEU=
Transaction Signature: AA==@G7ur/HpC3AuOmyeLBFtccptvstApuDEGChsHKzasF+JJvPg+B+jmRTvfkL8E2ACpW7DD4E83Hom8YOs2EzNXDw==@6TODHwm39WE6p+z1ulDzlbZdTA/i31ZHKIsAc5u7kNw=
Signed Authorities Bitmap: RoaringBitmap<[0, 1, 3]>
Transaction Kind : Transfer Object
Recipient : 0x1f7633037b5e185e162f51fca142fb6e8ebe50df
Object ID : 0xba561fb82aa38075be60c0fad30e0c6b615c0f2e
Version : SequenceNumber(2)
Object Digest : H60tIWie9FU/BfyYDmrMgrlltQA5A/4S5YP6lITbwqs=
----- Transaction Effects ----
Status : Success
Mutated Objects:
- ID: 0xba561fb82aa38075be60c0fad30e0c6b615c0f2e , Owner: Account Address ( 0x1f7633037b5e185e162f51fca142fb6e8ebe50df )
- ID: 0xbf8112a6abee9fd77fda6529aa0ec97fc735791a , Owner: Account Address ( 0x8e2591958b19311ece3d748852f4693908be8b3c )
Современное создание кошелька
Кошельки должны быть безопасными, но при этом легко доступными для их владельцев. Мы полагаемся на отраслевые стандарты при разработке пользовательских кошельков, оставаясь гибкими при изучении различных схем подписи.
В дополнение к спецификациям кошелька, которые мы поддерживаем в настоящее время, мы постоянно совершенствуем дизайн кошелька, который делает взаимодействие с Sui более безопасным и простым в использовании. Вскоре мы поделимся нашим дизайном предварительно одобренных транзакций кошелька. Вместо того, чтобы подписывать транзакции по одной, Sui Wallet делает онлайн-игры практичными, раскрывая весь потенциал быстрого исполнения в сети Sui.