Что такое токены ERC20 простыми словами

В криптосообществе много аббревиатур. Это может отпугивать новичков, особенно с учётом того, что часто эти обозначения представляют собой комбинацию букв и цифр. Если очень коротко, то токен ERC20 — это криптовалюта, созданная на платформе эфириума. Теперь разберёмся, что это значит.

Многие знают эфириум по криптовалюте эфир (Ether или ETH), которую можно встретить практически на каждой криптовалютной бирже. Одна из уникальных особенностей, которая отличает её от биткоина (по крайней мере на данный момент) состоит в том, что она предполагает возможность программирования смарт-контрактов. Смарт-контракт — это просто маркетинговое обозначение компьютерного кода, который можно использовать в блокчейне (подробнее о смарт-контрактах вы можете почитать в этой статье). По сути, вы можете написать код в блокчейне эфириума, и вместо простого хранения истории транзакций он будет хранить логические комбинации, на основе которых создаются привычные нам программы и приложения.

Но, если быть до конца точными, мы не можем просто назвать их приложениями. В конце концов, они не похожи на обычные приложения; эти приложения, которые записаны в блокчейне эфириума, децентрализованы по своей природе, потому что сама платформа эфириума децентрализована. Поэтому мы называем их децентрализованными приложениями (или даппами для краткости).

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

ERC20 — это стандарт, описывающий токены эфириума

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

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

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

Хранение токенов ERC20 и торговля ими

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

Не будем углубляться в технические детали того, почему не стоит этого делать; просто знайте, что биржи генерируют уникальные адреса для каждой монеты. Другими словами, ваш адрес для эфира и для токена ERC20 будут разными. Если вы попытаетесь отправить токен ERC20 на ETH-адрес биржи, она его не распознает и вам не будут зачислены токены ERC20. Однако в собственном кошельке вы можете хранить любые криптовалюты на основе эфириума.

Зачем строить даппы на эфириуме?

Это хороший вопрос, на который нет простого ответа. С момента запуска смарт-контрактов на эфириуме в 2015 году появилось много других блокчейнов с аналогичными функциями. Например, блокчейн NEO, который использует традиционные языки программирования, такие как Java, в то время как эфириум имеет свой собственный язык Solidity. Возможно, это вам ни о чём не говорит. Суть в том, что есть другие блокчейны, которые поддерживают смарт-контракты, отличающиеся от смарт-контрактов эфириума.

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

Теперь, когда кто-то скажет «токен эфириума» или «токен ERC20», вы сможете в общих чертах понять услышанное. Помните, что это всего лишь криптовалюта, построенная на блокчейне эфириума.

что это такое? Как они работают. Примеры

Говоря о криптовалюте, два наиболее распространенных слова, которые вы услышите, — это «монета» и «токен» среди других фраз и соответствующей терминологии.

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

Платежный токен является одним из наиболее важных типов токенов, так как он представляет собой самую чистую форму криптовалюты.

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

Итак, учитывая сказанное, давайте рассмотрим, что такое платежный токен, почему он так важен и какие криптовалюты подпадают под эту классификацию.

Термины

Токен. Крипто-токены представляют собой особый вид токенов виртуальной валюты, которые находятся на их собственных блокчейнах и представляют собой актив или утилиту.

ICO: выступает в качестве сборщика денег. Компания, желающая создать новую монету, приложение или услугу, запускает ICO. Затем заинтересованные инвесторы покупают токены этой компании, либо с использованием Фиата, либо с существующими цифровыми токенами, такими как Эфир или Биткоин. В обмен на их внесенные деньги (Фиат или другая криптовалюта) инвесторы получают новый токен проекта.

Блокчейн: Самый простой способ понять блокчейн — это думать о нем как о полностью прозрачной и постоянно обновляемой записи обмена инфоl

Пять простых шагов для понимания JSON Web Tokens (JWT) / Habr

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

Для начала рассмотрим формальное определение.

JSON Web Token (JWT) — это JSON объект, который определен в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д. и подписи (signature).
Кстати, правильно JWT произносится как /dʒɒt/

Простыми словами, JWT — это лишь строка в следующем формате header.payload.signature.
Предположим, что мы хотим зарегистрироваться на сайте. В нашем случае есть три участника — пользователь

user, сервер приложения application server и сервер аутентификации authentication server. Сервер аутентификации будет обеспечивать пользователя токеном, с помощью которого он позднее сможет взаимодействовать с приложением.

Приложение использует JWT для проверки аутентификации пользователя следующим образом:

1. Сперва пользователь заходит на сервер аутентификации с помощью аутентификационного ключа (это может быть пара логин/пароль, либо Facebook ключ, либо Google ключ, либо ключ от другой учетки).
2. Затем сервер аутентификации создает JWT и отправляет его пользователю.
3. Когда пользователь делает запрос к API приложения, он добавляет к нему полученный ранее JWT.
4. Когда пользователь делает API запрос, приложение может проверить по переданному с запросом JWT является ли пользователь тем, за кого себя выдает. В этой схеме сервер приложения сконфигурирован так, что сможет проверить, является ли входящий JWT именно тем, что был создан сервером аутентификации (процесс проверки будет объяснен позже более детально).

Структура JWT

JWT состоит из трех частей: заголовок header, полезные данные payload и подпись signature. Давайте пройдемся по каждой из них.

Хедер JWT содержит информацию о том, как должна вычисляться JWT подпись. Хедер — это тоже JSON объект, который выглядит следующим образом:

header = { "alg": "HS256", "typ": "JWT"}

Поле typ не говорит нам ничего нового, только то, что это JSON Web Token. Интереснее здесь будет поле alg, которое определяет алгоритм хеширования. Он будет использоваться при создании подписи. HS256 — не что иное, как HMAC-SHA256, для его вычисления нужен лишь один секретный ключ (более подробно об этом в шаге 3). Еще может использоваться другой алгоритм RS256 — в отличие от предыдущего, он является ассиметричным и создает два ключа: публичный и приватный. С помощью приватного ключа создается подпись, а с помощью публичного только лишь проверяется подлинность подписи, поэтому нам не нужно беспокоиться о его безопасности.

Шаг 2. Создаем PAYLOAD

Payload — это полезные данные, которые хранятся внутри JWT. Эти данные также называют JWT-claims (заявки). В примере, который рассматриваем мы, сервер аутентификации создает JWT

с информацией об id пользователя — userId.

payload = { "userId": "b08f86af-35da-48f2-8fab-cef3904660bd" }

Мы положили только одну заявку (claim) в payload. Вы можете положить столько заявок, сколько захотите. Существует список стандартных заявок для JWT payload — вот некоторые из них:

• iss (issuer) — определяет приложение, из которого отправляется токен.
• sub (subject) — определяет тему токена.
• exp (expiration time) — время жизни токена.

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

JWT, можете заглянуть в Wiki. Но стоит помнить, что чем больше передается информации, тем больший получится в итоге сам JWT. Обычно с этим не бывает проблем, но все-таки это может негативно сказаться на производительности и вызвать задержки во взаимодействии с сервером.

Шаг 3. Создаем SIGNATURE

Подпись вычисляется с использование следующего псевдо-кода:

const SECRET_KEY = 'cAtwa1kkEy'
const unsignedToken = base64urlEncode(header) + '.' + base64urlEncode(payload)
const signature = HMAC-SHA256(unsignedToken, SECRET_KEY)

Алгоритм base64url кодирует хедер и payload, созданные на 1 и 2 шаге. Алгоритм соединяет закодированные строки через точку. Затем полученная строка хешируется алгоритмом, заданным в хедере на основе нашего секретного ключа.

// header eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
// payload eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ
// signature -xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Шаг 4. Теперь объединим все три JWT компонента вместе

Теперь, когда у нас есть все три составляющих, мы можем создать наш JWT. Это довольно просто, мы соединяем все полученные элементы в строку через точку.

const token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature)
// JWT Token
// eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Вы можете попробовать создать свой собственный JWT на сайте jwt.io.
Вернемся к нашему примеру. Теперь сервер аутентификации может слать пользователю JWT.

Как JWT защищает наши данные?

Очень важно понимать, что использование JWT НЕ скрывает и не маскирует данные автоматически. Причина, почему JWT используются — это проверка, что отправленные данные были действительно отправлены авторизованным источником. Как было продемонстрировано выше, данные внутри JWT закодированы и подписаны, обратите внимание, это не одно и тоже, что зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных. Таким образом закодирование и подпись данных не защищает их. С другой стороны, главная цель шифрования — это защита данных от неавторизованного доступа. Для более детального объяснения различия между кодированием и шифрованием, а также о том, как работает хеширование, смотрите эту статью. Поскольку JWT только лишь закодирована и подписана, и поскольку JWT не зашифрована, JWT не гарантирует никакой безопасности для чувствительных (sensitive) данных.

Шаг 5. Проверка JWT

В нашем простом примере из 3 участников мы используем JWT, который подписан с помощью HS256 алгоритма и только сервер аутентификации и сервер приложения знают секретный ключ. Сервер приложения получает секретный ключ от сервера аутентификации во время установки аутентификационных процессов. Поскольку приложение знает секретный ключ, когда пользователь делает API-запрос с приложенным к нему токеном, приложение может выполнить тот же алгоритм подписывания к JWT, что в шаге 3. Приложение может потом проверить эту подпись, сравнивая ее со своей собственной, вычисленной хешированием. Если подписи совпадают, значит JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки. Таким образом, проверяя JWT, приложение добавляет доверительный слой (a layer of trust) между собой и пользователем.

В заключение

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

Что дальше?

Подумаем о безопасности и добавим Refresh Token. Смотрите следующую мою статью на эту тему.

Полезные ссылки

1. 5 Easy Steps to Understanding JSON Web Tokens (JWT)
2. Securing React Redux Apps With JWT Tokens
3. Зачем нужен Refresh Token, если есть Access Token?

По какому принципу работает CSRF Token защита и чем она отличается от Api Token? — Хабр Q&A

Здравствуйте, подскажите пожалуйста, в чем смысл защиты от CFRF в виде токена (насколько я понимаю — это позволяет даже от капчи отказаться), если это по сути уникальный код, который существует только на сервере для данного sessid?

Клиент спрашивает у сервера страницу
Сервер стартует сессию, отправляет юзеру sessid, создает токен, у себя сохраняет токен
Клиент спрашивает у сервера другую страницу
Сервер по его sessid вытаскивает из сессии его токен и запихивает в header ??? так это же пользователь токен в открытом виде заголовок получит, и толку тогда с такого токена? (в этом как бы месте википедия оставляет дыру, путая понятия «отправить заголовок» и «получить заголовок») — если мы при отдаче результата выставим заголовок, то это клиент получит Токен, сервер уже получил sessid и ему токен не впал три раза.

А по задумке этой защиты клиент свой токен получать не должен, все должно работать без него, поскольку:
а) заставить бабушку Нину вводить 64 значный буквенно цифровой токен — это продажи сразу в ноль
б) передача любых конфиденциальных данных пользователю без шифрования означает что любой человек, посмотрев ролик на ютубе и взяв ноутбук с линуксом получает пакет с токеном и становится юзером на раз-два
в) хранить токен в куках? зачем? там и так лежит sessid уникальность которого поддерживается на уровне сервера и его подменить нельзя оказалось можно

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

Вот при защите API, к которому будут обращаться коробки разные с железяками, тут один запрос тебе по имени-паролю выдает Токен, который ты сознательно копируешь и вставляешь в код в заголовок, который ты отправляешь серверу, при SSL/TLS его не расшифровать в обозримых по времени пределах, и потому это является доказательством, что твой компьютер это твой компьютер.

Но создание токена для пользователя при отправке форм? Каким образом это защитит от CFRF я не понимаю