rayls

Public blockchains offer transparency, but banks cannot treat every financial transaction like a public social media post. Customer balances, payment amounts and counterparties can be commercially or personally sensitive.
So the real question is not whether banks should use blockchain. It is how they can gain the benefits of onchain settlement without exposing confidential financial information.
1. Why ordinary public blockchains create a challenge
On a typical transparent blockchain, transactions can reveal wallet addresses, token amounts and patterns of financial activity. Even when real names are not directly attached to addresses, repeated transactions can sometimes help observers connect activity to particular entities.
For banks, this creates a practical trade-off:
Transparency: Transactions can be independently inspected.Confidentiality: Customer and institutional financial information needs protection.Compliance: Authorized parties may still need access to relevant records.
A financial network needs to balance all three rather than sacrificing one for another.
2. What is a private EVM?
An EVM-compatible blockchain supports smart contracts built around the Ethereum Virtual Machine. A private EVM combines that programmability with controlled access.
Rayls Sovereign takes this approach by giving each participating institution its own ledger, operated within the institution's environment. According to the official documentation, the institution controls its ledger, tokenized balances and smart contracts.
Multiple institutions can connect their individual ledgers through a permissioned Rayls Private Network rather than making every internal transaction publicly visible.
3. How does Rayls approach transaction privacy?
Rayls uses a combination of private institutional infrastructure and cryptographic techniques.
Separate institutional ledgers: Each institution maintains its own Rayls Sovereign ledger.
Encrypted communication: The Private Network Hub routes encrypted messages between institutions. The architecture documentation states that the Hub does not see the contents of the messages it carries.
Cryptographic verification: The Enygma framework uses zero-knowledge proofs, commitments and encryption to support private transfers while allowing the network to verify relevant transaction conditions.
This is an important distinction: privacy does not necessarily mean that a transaction leaves no verifiable evidence. A system can verify that a transaction is valid without publicly revealing all its underlying details.
4. Does privacy mean regulators cannot see anything?
No. Confidentiality and regulatory oversight are different requirements.
Rayls documents a selective-audit mechanism called Auditor View. A designated private-network auditor can receive decryption access to relevant network data without automatically receiving the ability to move assets.
This illustrates a useful design principle: viewing authority and transaction authority do not have to be identical.
The exact visibility available depends on the network configuration, permissions and information being audited. Privacy should not be interpreted as a guarantee that every participant or every transaction is invisible to every possible observer.
5. The trade-off most people overlook
Private institutional infrastructure introduces its own challenges.
Institutions must manage permissions, keys, network governance, security and operational infrastructure. Selective access also requires careful controls over who can inspect sensitive information.
There is another consideration: private settlement does not automatically create public liquidity. Institutions still need suitable connections and mechanisms to interact with external markets.
Rayls addresses this architectural challenge by designing its Sovereign, Private Network and Public Chain layers to interoperate. However, interoperability does not eliminate the need for security reviews, governance and appropriate controls.
Conclusion
Banks do not necessarily have to choose between blockchain programmability and financial confidentiality.
The more useful question is whether an architecture can provide controlled participation, private transaction data, verifiable settlement and appropriate audit access at the same time.
Rayls is one approach to this problem, combining institution-operated EVM ledgers with cryptographic privacy and connections to public blockchain infrastructure.
The bigger lesson is that institutional blockchain adoption depends on more than transaction speed. It also depends on who can see the data, who controls the infrastructure and how financial institutions remain accountable.
Sources consulted: Rayls official documentation, Rayls Sovereign, Private Network Technical Architecture, and Who Sees What: Privacy and Oversight.
$RLS #Rayls #Blockchain #Tokenization

Rayls에서 전송이 실패하면 내 토큰은 돌아올까?
크로스체인 전송에서 목적지 거래가 실패하면 출발지에서 처리된 토큰은 어떻게 될까? $RLS
토큰을 다른 체인으로 옮길 때 출발지에서는 자산이 잠기거나 소각될 수 있다. 그런데 목적지에서 처리가 실패하면 자산 상태를 복구하는 절차가 필요하다.
Rayls의 공식 문서는 이 상황에 대응하는 복구 메커니즘을 설명한다. 하지만 공개 코드를 함께 살펴보면 추가로 확인해야 할 부분이 드러난다.
Public Chain 전송과 관련된 기존 계약 코드에도 폐기 표시가 있기 때문이다.
그렇다면 Rayls의 토큰 복구 기능은 현재 어떻게 구현돼 있을까?
공식 문서와 공개 코드를 비교해 봤다.
1. 공식 문서가 설명하는 토큰 복구 방식
Rayls의 공식 문서는 Sovereign과 Public Chain 사이의 전송 방식과 실패 처리 절차를 설명한다.
공식 문서:
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
이 경로는 Private Network Hub를 거치는 기관 간 전송 경로와 구분된다. Public Chain 경로는 별도의 계약 구성과 Public Relayer를 사용하며, RN 계열 계약을 통해 메시지를 처리한다.
전송 방향에 따라 자산 처리 방식도 달라진다.
Sovereign → Public Chain
• 출발지에서 토큰을 잠근다.
• 목적지에서 대응하는 토큰을 발행한다.
• 목적지 거래가 실패하면 복구 데이터를 이용해 출발지의 토큰을 해제하는 절차를 진행한다.
Public Chain → Sovereign
• 공개 체인에서 토큰을 소각한다.
• 목적지에서 기존에 잠겨 있던 토큰을 해제한다.
• 목적지 거래가 실패하면 공개 체인에서 토큰을 다시 발행하는 복구 절차를 진행한다.
공식 문서에 따르면 Public Relayer는 전송 과정에서 복구 데이터를 준비하고 저장한다. 이후 목적지 거래의 영수증 상태를 확인해 실행 실패가 확인되면, 저장된 복구 데이터를 사용해 출발지에서 복구 절차를 진행한다.
따라서 Rayls의 공식 문서에는 Public Chain 전송 실패에 대응하는 구체적인 복구 설계가 명시돼 있다.
하지만 문서에 설계가 설명돼 있다는 사실만으로 현재 메인넷에서 사용되는 구현과 실제 복구 성공 여부까지 확인할 수 있는 것은 아니다.
2. 공개 코드에서 발견한 폐기 표시
다음으로 Rayls Sovereign Contracts 저장소의 `RaylsErc20Handler.sol`을 살펴봤다.
코드:
https://github.com/raylsnetwork/rayls-sovereign-contracts/blob/main/src/rayls-protocol-sdk/tokens/RaylsErc20Handler.sol
이 파일에는 Public Chain 전송과 관련된 함수가 구현돼 있다.
• `teleportToPublicChain()` — Public Chain으로 토큰을 보내는 전송 경로
• `receiveTeleportFromPublicChain()` — Public Chain에서 온 전송을 처리하고 잠긴 토큰을 해제하는 경로
• `revertTeleportToPublicChain()` — 목적지에서 전송 처리가 완료되지 않았을 때 잠긴 토큰을 복구하는 경로
특히 `revertTeleportToPublicChain()`의 주석은 목적지에서 토큰 수령을 완료할 수 없는 경우 잠긴 토큰을 복구한다고 설명한다. 함수 내부에서도 잠긴 잔액을 해제하고 토큰을 원래 보낸 주소로 돌려주는 로직을 확인할 수 있다.
그런데 이 함수에는 다음과 같은 폐기 관련 주석이 붙어 있다.
`@custom:deprecated Decommissioning Teleport (vanilla, atomic).`
같은 파일의 다른 Teleport 관련 함수에도 유사한 표시가 존재한다.
즉, 폐기 표시가 기존 Private Network의 Teleport 코드에만 있는 것은 아니다. 공개된 기존 `RaylsErc20Handler`의 Public Chain 관련 함수에서도 확인된다.
이 부분은 현재 공식 문서와 함께 살펴볼 필요가 있다. 공식 문서는 Public Chain 경로의 복구 절차를 설명하지만, 공개된 기존 계약 코드에는 해당 전송과 복구를 처리하는 함수에 폐기 표시가 있기 때문이다.
그렇다고 곧바로 현재 Public Chain 복구 기능이 폐기됐다고 결론 내릴 수는 없다. 주석이 붙은 코드의 버전과 현재 운영 환경에서 사용되는 구현이 일치하는지 확인해야 하기 때문이다.
여기서 중요한 질문은 폐기 표시의 존재 자체가 아니라, 그 표시가 현재 운영 중인 Public Chain 전송 경로에 어떻게 적용되는가다.
3. 문서와 코드의 차이만으로 운영 상태를 판단할 수 있을까?
현재 확인한 자료는 세 가지로 나눌 수 있다.
① 공식 문서
Public Chain 전송 실패 시 복구 데이터를 이용해 토큰 상태를 복구하는 절차를 설명한다.
② 공개 계약 코드
기존 `RaylsErc20Handler.sol`에 전송 및 복구 로직이 구현돼 있다. 다만 관련 함수에는 폐기 표시도 존재한다.
③ 실제 운영 환경
공개된 코드와 현재 메인넷에 배포된 계약의 관계는 아직 입증하지 못했다.
이 자료만으로 복구 기능이 중단됐다고 판단하는 것은 성급하다. 폐기 주석만으로 현재 메인넷에서 어떤 계약과 버전이 사용되는지 알 수 없기 때문이다.
반대로 공식 문서에 복구 절차가 설명돼 있다는 이유만으로 현재 운영 환경에서 모든 실패가 성공적으로 복구된다고 보장할 수도 없다.
실제 운영 상태를 판단하려면 다음 항목을 연결해서 확인해야 한다.
• 현재 메인넷에서 사용되는 계약 주소
• 해당 주소에 배포된 계약의 구현 버전
• 실제 운영 중인 Public Relayer의 버전과 처리 경로
• 목적지 실행 실패와 출발지 복구 거래를 연결하는 실제 기록
이번 조사에서는 공식 문서의 복구 설계와 공개 코드의 관련 함수 및 폐기 표시를 확인했다. 그러나 운영 계약 주소와 구현 버전을 연결하고, 실제 실패 거래가 복구 완료까지 이어졌다는 메인넷 거래 사례를 입증하지는 못했다.
따라서 현재 근거로는 복구 기능이 정상 운영 중이라고 확정할 수도, 폐기됐다고 확정할 수도 없다.
결론: 복구 설계는 문서에 명시돼 있지만, 운영 상태는 추가 검증이 필요하다.
이번 조사에서 확인한 사실은 두 가지다.
첫째, Rayls의 공식 문서는 Public Chain 전송 실패에 대응하는 복구 절차를 설명한다.
둘째, 공개된 기존 `RaylsErc20Handler.sol`에는 관련 복구 로직이 구현돼 있지만, Public Chain 전송 및 복구와 관련된 함수에도 폐기 표시가 있다.
이 두 사실을 함께 살펴보면 현재 운영 상태를 판단하기 위해 무엇을 추가로 확인해야 하는지 분명해진다. 공개된 코드의 주석만으로 기능의 현재 상태를 단정하지 말고, 실제 배포 계약과 구현 버전, 복구 거래까지 연결해서 확인해야 한다.
현재 자료로 내릴 수 있는 결론은 Rayls의 공식 문서에 복구 설계가 명시돼 있고, 공개 코드에 관련 구현과 폐기 표시가 함께 존재한다는 것이다. 현재 메인넷에서 해당 기능이 어떤 버전으로 운영되는지, 실제 실패 거래에서 복구가 완료됐는지는 아직 입증하지 못했다.
토큰 전송의 안전성을 평가할 때는 복구 기능이 문서에 있다는 사실만으로 판단해서는 안 된다. 해당 기능이 현재 어떤 코드와 배포 환경에서 실행되는지까지 확인해야 한다.
참고 자료
• Rayls 공식 문서 — Connecting Rayls Sovereign to the Public Chain
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
• Rayls 공식 문서 — RaylsErc20Handler
https://docs.rayls.com/docs/raylserc20handler
• Rayls Sovereign Contracts — RaylsErc20Handler.sol
https://github.com/raylsnetwork/rayls-sovereign-contracts/blob/main/src/rayls-protocol-sdk/tokens/RaylsErc20Handler.sol
• Rayls Sovereign Relayer
https://github.com/raylsnetwork/rayls-sovereign-relayer
#RLS #Rayls

Что я выяснил, изучая консенсус, архитектуру расчётов и квитанции о транзакциях в Rayls.
Я начал с простого вопроса:
Если блокчейн обещает окончательность менее чем за секунду, значит ли это, что вся транзакция завершается быстрее чем за секунду?
На первый взгляд ответ кажется очевидным. Транзакция подтверждается, сеть достигает консенсуса — операция завершена.
Но финансовая инфраструктура устроена сложнее.
Транзакция может быть зафиксирована в одном реестре, в то время как более масштабная операция всё ещё зависит от другого реестра, ретранслятора, проверки доказательства или выполнения на стороне сети-получателя.

$RLS
Пересматривая код Rayls Relayer, я заметил кое-что странное.
Если Relayer отвечает за передачу сообщения, разве у него не должно быть права RELAYER и на "executeMessage()"?
Но когда я проследил за реальным кодом, оказалось, что это не так.
Напротив, в Rayls права на передачу сообщений и их фактическое выполнение разделены.
В Public Chain Relayer впервые появляется в "PublicRNEndpoint.receivePayload()".
Здесь сообщение не выполняется напрямую,

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

В прошлый раз я прогнал публичный код доказательства, опубликованный Rayls, и измерил: для анонимной группы из 6 человек на каждую запись уходит 1,96 секунды. Но в той статье было три фразы, которые являются выводами, а не измерениями — я это понимаю. На этой неделе я заменил машину на 2-ядерную и добавил несколько наборов данных, чтобы вернуться и восполнить те три фразы измерениями.
Сначала уточню, какое отношение у этой статьи к предыдущей, чтобы читатели не подумали, что это просто повтор публикации. В прошлый раз измерялось время доказательства для режимов на 2 человека и на 6 человек в однопроцессорной среде; эти два числа при повторном тестировании почти не изменились. В этой статье всё новое — это те три вещи, которые в прошлой работе не удалось измерить и можно было только предположить.

В таблице сравнения поставщиков Rayls на девять строк, и я выбрал строку «приватность». Причина очень простая: приватность важна, а Besu — с открытым исходным кодом, так что я могу проверить и документацию, и код.
В таблице Rayls отмечен галочками в обеих строках — «изолирующая приватность» и «криптографическая приватность», а Besu — только в первой строке. Я собирался перепроверить по их собственной документации, поэтому я посмотрел документацию Besu, а затем скачал его код и пересчитал всё.
Вывод не в том, что «Besu не подходит». Настоящее различие такое: эти две компании разместили приватность на разных уровнях, и Besu перенёс это раньше, чем многие думают.

19 сентября Rayls опубликовал статью (Privacy has a price). В заголовке было написано honest math, но по всей статье был дан лишь один числовой диапазон: доказательство занимает от нескольких сотен миллисекунд до нескольких секунд. Я несколько недель подряд писал про приватную архитектуру Rayls. На этот раз делюсь с вами новым материалом: я скачал опубликованный код доказательства, реально прогнал его десятки раз — и спешу поделиться этой интересной находкой!
Сначала скажу, о чём был блог. Его ключевые тезисы можно сжать в две фразы. Первая — где именно цена: конфиденциальные транзакции дороже прозрачных — дорого именно генерировать zk-доказательства, а проверка при этом получается дешевле; для базового конфиденциального перевода доказательство на обычном коммерческом оборудовании занимает от нескольких сотен миллисекунд до нескольких секунд. Вторая — что стоит спрашивать: организации не должны смотреть только на TPS, нужно спрашивать, каков будет throughput при той приватности и уровне аудита, которые им реально нужны, и при работе с реальной бизнес-нагрузкой. В блоге считают, что объём расчётов между банками небольшой и полностью укладывается в возможности систем конфиденциальных расчётов.

Я начал стейкать RLS ещё с этапа предварительного обещания, так что читать официальные материалы — скорее привычка. После появления названия Sovereign большинство обсуждений сводилось к вопросу: «это просто сменили имя?». Я думаю, что вопрос задан наоборот. Неважно, как называется, важно, что именно поменялось внизу, а также сколько сама контролирующая организация может получить из того, что она сможет самостоятельно проверить во время due diligence. В этой статье для каждого числа я указал точный источник; вы можете воспроизвести всё по шагам.
Сначала про одну вещь: на прошлой неделе я писал статью про аудируемость, и некоторые читатели, возможно, её уже видели.
В этой статье большая часть материала — новая: она взята из репозитория кода Axyl, из аудит- директории в этом репозитории, а также со страницы документа Axyl с бенчмарками производительности — с этими местами я ранее не работал. Лишь небольшой раздел про управление ключами продолжает выводы из предыдущей публикации; там я отмечу это отдельно. Разделять «новое» и «старое» я буду потому, что «что я нашёл на этой неделе» и «что я уже проверял раньше» должны быть для читателя различимы.

Честно говоря, когда я впервые увидел эти три аббревиатуры рядом, мне показалось, что это три ответа на один и тот же вопрос: кто быстрее, кто безопаснее — выбирай один и дело с концом. Потом я понял: ставить их рядом в рейтинге — всё равно что спрашивать «какой лучше инструмент — молоток, отвёртка или гаечный ключ»: ответ зависит от того, у тебя гвоздь, шуруп или болт.
Каждый из них решает на самом деле три проблемы, которые по ошибке сводят в одну.
Первая проблема такая: я хочу доказать, что нечто истинно, но для доказательства нужны данные, которые слишком чувствительны, и я не хочу показывать их тебе. Банк хочет показать регулятору, что «эта сделка законна, полномочия в порядке, нет повторов», но не желает раскладывать суммы и плательщика/получателя по бухгалтерским книгам. Такое доказательство, при котором требуется правда, но без раскрытия данных,— это вотчина ZK. В чём прелесть: гарантия рождается из математики, а не из «я обещаю, что не загляну». Регулятор или аудиторы, получившие ключ верификации, могут проверить вывод, но не могут добраться до базовых данных. Цена тоже вполне реальная: ZK хорошо доказывает свойства данных, но плохо подходит для совместных вычислений нескольких сторон, когда у каждой нет полного набора данных, и при этом требует существенно больше вычислительных ресурсов, чем открытый текст.

Братья, я всё время прятался и наблюдал за сообществом Rayls. Я знаю, что многие недовольны командой, и я тоже, но команда действительно работает и всё время старается. Просто команда Rayls идёт по пути соблюдения регламентов. Братья, ни в коем случае не сдавайтесь, всё зависит от времени. Я верю, что в итоге команда Rayls предоставит нам экзаменационную работу, которая нас удовлетворит. Я хочу поделиться с вами хорошими новостями — о том, что недавно команда Rayls подключила RPC. Это очень важное событие！！
Коротко и по делу
Что такое RPC
Вы можете понять RPC как выделённую линию между приложением и блокчейном.

Я думаю, что в уведомлениях о блокировке обычно волнует лишь одна вещь: можно ли проверить это обещание. В большинстве проектов «блокировка команды» в итоге сводится к одной фразе — вы можете либо верить, либо не верить. На этот раз иначе, поэтому я проверил это on-chain.
Сначала обозначим факты. Parfin — ключевой технологический партнер за спиной Rayls: он отвечает за разработку приватных узлов, приватной сети, privacy-фреймворка Enygma и блокчейна Rayls. В качестве вознаграждения за работу до TGE он получил 1 070 493 535 RLS — около 11% от первоначального общего предложения в 10 млрд.
Эти токены ранее хранились у институционального кастодиана на Ethereum. Причина довольно практичная: на момент TGE блокчейн Rayls еще не был запущен, поэтому их пришлось сначала держать в хранилище. Сейчас сеть работает, и эти токены перенесли в блокчейн Rayls, где они заблокированы в публично верифицируемом смарт-контракте; при этом время разблокировки перенесено с декабря 2026 года на декабрь 2027 года.

В крипто-сообществе каждую неделю можно увидеть: «какой-то крупный традиционный финансовый игрок выходит в блокчейн». Я теперь такие заголовки в основном просто пролистываю, потому что в большинстве случаев всё в итоге заканчивается инновационными лабораториями: выпустят пресс-релиз — и дальше тишина. Проверить правду довольно простым критерием: обычный клиент в своём приложении — может ли он напрямую открыть и воспользоваться сервисом?
XP Inc. На этот раз этот стандарт был пройден.
Сначала нужно чётко описать эту компанию, потому что масштаб определяет значимость вопроса. XP — бразильская инвестиционная платформа, котирующаяся на NASDAQ, тикер XP. Я сверил данные на их странице для инвесторов за I квартал 2026 года: активы клиентов — порядка 1,529 млрд бразильских реалов, точнее 1,529 трлн; консультантов — более 18 000 человек; за последние двенадцать месяцев общая выручка — 19,8 млрд реалов; прибыль до налогообложения — 5,8 млрд реалов.

Я начал стейкать RLS еще на этапе предподтверждения: в обычное время читаю официальный блог, в основном чтобы понять, повлияет ли на меня моя позиция. Но статья про квантование от 30 августа — другая: по сути, она учит организации тому, как делать закупки, и мне, как частному инвестору, к этому напрямую отношения нет. Но я все равно дочитал, потому что в самом начале она установила довольно жесткое правило, а это правило потом вернуло меня обратно к самой статье — к тому, что в ней про меня.
То правило такое: формулировка про «квантовую безопасность» — если не указано четко, какой именно стандартизированный алгоритм применяется и на каком уровне параметров, то это не утверждение, а просто ярлык.

В прошлой статье я рассказал о самом факте открытия стейкинга. Но в чате/в бэкэнде больше всего братья спрашивали одну и ту же фразу: «Как именно это сделать?» Поэтому на этот раз я с нуля и до конца заново прошёл весь процесс, записал каждое действие и все места, где чаще всего можно застрять — просто повторяйте по шагам.
Ссылка на прошлую статью здесь: 质押开放给所有人了,但有几件事最好先知道
Сначала скажите, для кого эта статья. Если вы вообще не сталкивались с Rayls и даже с такими словами, как «кошелёк» и «мост», не очень знакомы — значит, эта статья написана именно для вас. Каждое профессиональное название я сразу же коротко объясню.

В прошлый раз, когда я писал статью про XP, меня всё время мучил один вопрос: после того как выпускается институциональный стейблкоин вроде USDXP, как он вообще участвует в реальных трансграничных расчётах? Эта статья как раз закрывает мою догадку — и попутно впервые помогает мне понять одно слово: «стейблкоиновый сэндвич» (стаблкоин-три смэндвич).
Сначала объясню это слово: оно очень образное. Одно международное платежное поручение: с двух сторон — фиатная валюта, а между ними — слой публичного стейблкоина. Плательщик обменивает свою фиатную валюту на долларовый стейблкоин, стейблкоин на блокчейне выполняет трансграничные расчёты, а затем получатель снова обменивает его на свою фиатную валюту. Похоже на два ломтика хлеба с прослойкой посередине? Это как раз то, как отрасль начала описывать трансграничные расчёты со стейблкоинами.

Я начал делать стейкинг с той партии предопределённых обязательств в июне, поэтому я уже прошёл этот процесс один раз. На этот раз его открыли для всех, и многие из моих знакомых спрашивают, как это сделать и на что обратить внимание — так что я решил всё один раз подробно расписать.
Сначала поговорим о самих изменениях.
Rayls использует делегированное proof-of-stake: валидаторы запускают ноды, производят блоки и обеспечивают безопасность блокчейна. Обычным держателям не нужно самим поднимать ноду — они могут делегировать свои RLS какому-то валидатору и делиться частью наград за стейкинг.
Этот механизм запустили ещё в июне, но тогда он был доступен только кошелькам, которые участвовали в плане предопределённых обязательств и в мероприятии по ликвидному семени. Те участники заранее заблокировали свои монеты до мейннета: официально им дали трёхмесячный бонус к годовой доходности 55%, а ещё даже отправили по 1 USDr в каждый кошелёк, который соответствует условиям, чтобы у них не возникло проблем даже с gas.

Я изучал документацию Rayls, и одна вещь, которая сначала казалась мне непонятной, — это различие между Privacy Node, Private Network и Public Chain.
После того как я разобрался, как они связаны, стало намного легче это понять.
У каждого своя роль.
1. Privacy Node: собственная блокчейн-инфраструктура учреждения
Privacy Node Rayls — это совместимая с EVM цепочка, управляемая одним учреждением.
То, что происходит внутри учреждения, остается внутри его собственной среды.
Он может выпускать токены, управлять балансами, запускать смарт-контракты и обрабатывать свою внутреннюю активность.

Я начал делать стейкинг RLS ещё с этапа предварительных обещаний, читать официальный блог — это, по сути, вошло в привычку. 12 сентября в этой статье про проверяемость (auditable) во второй половине перечислены шесть стандартов, и сказано, что они все выполняются математическим образом по построению. Я с этим согласен, но фраза «выполняется по построению» — это утверждение, которое можно проверить, а не то, что нужно просто принимать на веру. Поэтому я потратил неделю: по каждой из этих шести позиций я искал соответствующие вещи в публичном исходном коде, технической документации и в ончейн-интерфейсах; теперь делюсь этим с вами.
Сначала — о классификации. Я считаю, что это полезнее, чем большинство дискуссий на тему «приватность или прозрачность». Для проверяемости есть три пути: математическое принуждение — когда всё заложено прямо в криптографических конструкциях; аппаратное доверие — опираясь на целостность доверенной среды исполнения (trusted execution environment); и стратегический контроль доступа — то, кто что может увидеть, определяется настройками со стороны оператора сети.