rls

Kompensasiyaedici əməliyyatların, qismən hesablaşmanın və zəncirlərarası ödənişlərdə atomikliyin məhdudiyyətlərinin təhlili
Bir çox qurum və tərtibatçı hələ də göndərənin zəncirində əməliyyat qəbzinin uğurlu olmasını ödənişin tamamlandığının sübutu hesab edir. Zəncirlərarası sistemlərdə bu, çox vaxt belə olmur.
Texniki sənədləri nəzərdən keçirdikdə və idarə olunan mühitlərdə əsas davranışı müşahidə etdikdə, bir nümunə ardıcıl olaraq üzə çıxır: mənbə zəncirindəki debet əməliyyatı uğurla təsdiqlənə bilər, halbuki təyinat zəncirində sonrakı mərhələdə xəta baş verə bilər. Bu baş verdikdə, vəsait avtomatik olaraq geri qaytarılmır. Sistem adətən **kompensasiyaedici əməliyyat** icra edir.

Rayls의 Sovereign Contracts 저장소를 살펴보면서 Private Network Hub(PNH)의 역할별 권한 설정을 확인했다.
단순히 각 역할이 어떤 기능을 수행하는지 소개하는 대신, 실제 구현 코드와 권한 설정 스크립트, 공식 문서가 서로 일치하는지 비교해 봤다.
권한 관리 시스템에서는 역할 이름만 아는 것으로 충분하지 않다. 코드가 어떤 권한을 지원하는지, 설정 스크립트가 어떤 매핑을 실행하는지, 문서가 이를 어떻게 설명하는지까지 함께 살펴봐야 하기 때문이다.
비교 과정에서 확인할 만한 지점 세 가지를 발견했다.
1. 복수 역할 매핑을 지원하는 구현과 주석의 차이
먼저 "src/privateHub/AccessControl/libraries/AccessManagerRoleConfigLib.sol"을 살펴봤다.
이 파일의 "addFunctionAllowedRoles()" 구현은 전달받은 여러 역할 ID를 순회하면서 해당 함수 선택자에 대한 역할 비트맵을 갱신한다.
즉, Rayls의 커스텀 권한 관리 구현은 하나의 함수에 여러 역할을 연결할 수 있는 구조다.
그런데 역할을 활성화하는 "hardhat/tasks/interact/access-control/activate-business-roles-pnh.ts"에는 하나의 함수에 하나의 역할만 매핑할 수 있다는 취지의 주석이 나온다.
여기서 중요한 점은 주석과 실제 구현을 구분해서 읽어야 한다는 것이다.
주석의 설명만 보면 복수 역할 매핑에 제한이 있는 것처럼 이해할 수 있지만, 실제 구현에서는 여러 역할 ID를 처리하는 로직을 확인할 수 있다.
따라서 이 부분은 설정 스크립트의 설명과 실제 권한 관리 구현을 함께 대조해야 하는 지점이다.
2. TOKEN_MANAGER의 권한 설명이 문서마다 다르다
두 번째는 "TOKEN_MANAGER"의 권한 설명이다.
Rayls의 공식 Private Network Roles 문서는 "TOKEN_MANAGER"에 매핑된 함수가 없다고 설명한다.
반면 저장소의 역할 참조 문서에는 "TokenRegistry.updateStatus()"와 "TOKEN_MANAGER"의 연결이 기재되어 있다.
같은 역할을 설명하는 문서 사이에 차이가 존재하는 것이다.
이 차이는 단순한 표현의 문제가 아니다.
개발자가 역할별 권한을 확인하거나 운영자가 설정을 검토할 때, 어느 문서를 기준으로 판단해야 하는지 혼란이 생길 수 있다. 특히 문서만 보고 권한을 파악한다면 실제 코드나 설정과 다른 이해를 할 가능성이 있다.
다만 문서가 서로 다르다는 사실만으로 어느 쪽이 현재 배포 환경의 권한을 정확하게 반영하는지 단정할 수는 없다.
확실하게 말할 수 있는 것은 두 문서의 설명이 서로 일치하지 않으며, 기준이 되는 권한 정보를 명확히 할 필요가 있다는 점이다.
3. TeleportV1.setLockTime()의 출력 요약과 실제 매핑 목록
세 번째는 권한 활성화 스크립트의 출력 요약이다.
"activate-business-roles-pnh.ts"의 마지막 콘솔 출력 요약에는 다음과 같은 매핑이 표시된다.
"TeleportV1.setLockTime() → PRIVATE_NETWORK_OPERATOR"
그런데 스크립트에서 실제 매핑 작업을 담고 있는 "mappingTxs" 목록에서는 이 매핑을 수행하는 호출을 확인할 수 없다.
여기서는 출력 메시지와 실제 실행 작업을 구분해야 한다.
콘솔에 특정 권한 매핑이 표시된다고 해서 그 문구만으로 실제 매핑 트랜잭션이 실행됐다고 판단할 수는 없다. 실행하려는 작업 목록과 결과를 설명하는 출력 요약은 서로 다른 역할을 하기 때문이다.
따라서 이 항목은 설정 스크립트의 출력과 실제 매핑 목록을 대조해 볼 필요가 있는 사례다.
다만 이 코드만으로 실제 배포된 네트워크에서 "TeleportV1.setLockTime()" 권한이 설정되어 있는지, 또는 설정되어 있지 않은지까지 결론 내릴 수는 없다. 그 부분은 별도의 온체인 조회로 검증해야 한다.
세 가지 발견에서 공통으로 보이는 점
이번에 비교한 내용은 서로 다른 유형의 불일치다.
- 구현과 주석: 실제 코드가 지원하는 구조와 주석의 설명을 대조해야 한다.
- 문서와 문서: 같은 역할에 대해 서로 다른 권한 정보를 제공하고 있다.
- 출력 요약과 실행 목록: 표시된 설명만으로 실제 실행 여부를 판단해서는 안 된다.
이 세 가지를 같은 종류의 오류라고 단정할 수는 없다. 하지만 모두 권한 설정을 검토할 때 설명 문구만 읽는 것으로는 충분하지 않다는 점을 보여준다.
코드가 지원하는 기능, 설정 스크립트가 실행하는 작업, 문서가 설명하는 권한은 서로 연결되어 있어야 한다. 이 정보가 어긋나면 개발자와 운영자가 의도된 권한 구조를 정확하게 이해하기 어려워질 수 있다.
결론
이번 조사의 핵심은 Rayls의 권한 관리 시스템에 문제가 있다고 단정하는 것이 아니다.
실제 구현 코드와 설정 스크립트, 문서를 비교해 어디에서 설명이 서로 달라지는지 구체적으로 찾아냈다는 것이다.
그리고 소스 코드에서 확인한 사실과 별도의 검증이 필요한 사항을 구분하는 것도 중요하다. 저장소에서 불일치를 발견했다고 해서 실제 배포 환경에서도 동일한 문제가 발생한다고 볼 수는 없기 때문이다.
인프라를 제대로 이해하려면 기능 설명을 읽는 데서 멈추지 않고, 코드와 설정을 직접 대조해야 한다.
이번 비교를 통해 다시 확인한 것도 바로 그 점이다.
#RLS

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

Əvvəlki iki məqalədə Rayls-in sübut kodunu bir bulud serverində sınaqdan keçirmişdim, amma rəqəmlər yalnız bir maşından alınmışdı və test kodunu oxucuların asanlıqla təkrarlaya biləcəyi yerdə yerləşdirməmişdim. Bu dəfə test kodunu GitHub-da açıq yayımladım, testi GitHub-un öz serverlərində işlətdim, üç CPU növünü sınaqdan keçirdim və hər kəs jurnallara baxa bilər.
Qısa cavabı əvvəlcədən deyim. Rayls Enygma-nın məxfi köçürmə sxemində 6 nəfərlik anonim dəsti nümunə götürsək, bir köçürmənin sıfır bilik sübutunu yaratmaq 1 vCPU-da 1,55–1,95 saniyə, 4 vCPU-da isə 0,63–0,71 saniyə çəkir. Sübutun yoxlanması təxminən 1 millisaniyədir. Xidmət müəyyən ölçüdə köçürməni ilk dəfə emal edəndə sübut açarını yaddaşa yükləmək üçün əlavə 1,9–2,9 saniyə də tələb olunur. Sorğular ardıcıl emal edilərsə, 4 vCPU-lu bulud serveri saniyədə 1,4–1,6 sübut yarada bilər.

Mən iyun ayında verilən həmin pre-commit (öncədən razılıq) partiyasından başlayaraq staking etməyə başlamışam, yəni bu prosesi artıq bir dəfə keçmişəm. Bu dəfə hər kəs üçün açıqdır; ətrafımdakı çoxları mənə necə əməliyyat etməli, nələrə diqqət yetirməli olduğumu soruşur. Ona görə də hamısını bir dəfə yazıb aydınlaşdırım.
Əvvəl dəyişikliklərin özünü deyim.
Rayls delegasiya edilmiş proof-of-stake (stakingin sübutu) istifadə edir: validator (verifikator) node işlədir, blok çıxarır və ümumi blokçeynin təhlükəsizliyini təmin edir. Adi iştirakçılara özləri node işlətmək lazım deyil; əlindəki RLS-i istənilən bir verifikatora delegasiya edə bilər və staking mükafatının bir hissəsini paylaşa bilər.
Bu mexanizm iyun ayından işə düşmüşdü, amma o vaxt yalnız pre-commit planında iştirak etmiş və likvidlik (likvidlik) seed fəaliyyətinə qatılan pul kisələri üçün açıq idi. O partiyadakı insanlar mainnetdən əvvəl pullarını kilidləyibmiş; rəsmi olaraq 3 ay müddətinə 55% illik bonus verilib, hətta hər şərtə uyğun pul kisəsinə 1 ədəd USDr paylayıblar ki, qaz (gas) belə tapmasınlar.