📝 Теперь вы знаете:
- Первый тип аутентификации - это аутентификация на основе подписи, например, в случае внешнего сообщения кошелек считывает первую часть данных, проверяет правильность подписи, а затем работает с остальной частью сообщения.
- Второй механизм - аутентификация отправителя сообщения. Все внутренние сообщения в TON идентифицируются отправителем сообщения, который гарантированно будет правильным и безопасным протоколом TON. Таким образом, каждый раз, когда контракт получает внутреннее сообщение, он точно знает, из какого другого контракта было получено сообщение.
- Третий строится поверх отправителя сообщения. Поскольку адреса в экосистеме TON - это не просто уникальные идентификаторы контрактов, но и криптографически безопасные хэши кода контракта и данных, и, более конкретно, исходный код и данные, поэтому они не меняются при изменении данных. И поскольку эти адреса являются криптографическими обязательствами к этому коду, вы можете проверить, какой код говорит на другом конце, проверив отправителя сообщения.
- Четвертый тип аутентификации - это то, о чем не стоит забывать. Это вообще отсутствие аутентификации. Это важный шаблон, который вступает в игру, если вы создаете по-настоящему децентрализованные приложения.
📚Чтение Заметок
В этом уроке обсуждаются различные методы авторизации сообщений.
Обзор всех типов аутентификации
- Аутентификация с подписью.
❗Любое событие в блокчейне TON должно начинаться с внешнего сообщения. Всякий раз, когда внешнее сообщение приходит в кошелек, оно считывает 64 байта данных 6️⃣4️⃣, то есть подпись для остальной части сообщения, проверяет подпись с ее публичным ключом, а затем рассматривает остальную часть сообщения как инструкции для отправки других сообщений другим контрактам внутри блокчейна.
- Аутентификация отправителя сообщения.
Все внутренние сообщения в TON идентифицируются отправителем сообщений, который гарантированно является правильным и безопасным 🔓 протоколом TON. Каждый раз, когда контракт получает внутреннее сообщение, он точно знает, из какого другого контракта было получено сообщение. И это намного дешевле и мощнее, чем проверка подписей.
- Проверка ДНК на доверенный код.🙌
Поскольку адреса в экосистеме TON являются не просто уникальными идентификаторами контрактов, но и криптографически безопасными хэшами кода контракта и данных, они не меняются при изменении данных. Поскольку эти адреса являются криптографическими обязательствами к этому коду, вы можете проверить, какой код говорит на другом конце, проверив отправителя сообщения.
- Отсутствие аутентификации для сопротивления цензуре.
❓ Разве не небезопасно не аутентифицировать сообщения? В определенных ситуациях именно здесь на самом деле лежит безопасность. Вы можете иметь дело с системой, которая должна быть устойчива к цензуре, как децентрализованный пул ставок
