안녕하세요, 프로토콜 23 발표 블로그에 오신 것을 환영합니다. 프로토콜 23은 8개의 새로운(!!) 핵심발전제안서(CAP) 아래에 자세히 설명된 Stellar 네트워크로.
메인넷 투표는 2025년 8월 14일에 진행되며, CAP는 2025년 6월 30일에 테스트넷에서 활성화됩니다.
자세한 내용을 살펴보기 전에, 프로토콜 23의 새로운 기능을 간략히 요약해 드리겠습니다.
SEP-0041: 이제 네트워크에서 값을 이동하는 모든 Stellar 작업에 대해 Soroban 토큰 인터페이스 이벤트를 내보낼 수 있습니다. CAP-0067을 정독하여 자세히 알아보십시오.
Soroban 상태를 RAM으로 이동함으로써 Soroban 비용이 절감됩니다. CAP-0062 및 CAP-0066에 대해 자세히 알아보십시오. CAP-0065에 설명된 모듈 캐시로 인해 비용도 절감됩니다.
보관된 항목의 수동 복원은 더 이상 필요하지 않습니다. CAP-0062 및 CAP-0066에서 자세한 내용을 읽어보십시오.
Soroban 원장당 CPU 용량은 이제 CAP-0063에 설명된 병렬 트랜잭션 실행 덕분에 크게 증가할 수 있습니다. CAP-0062 및 CAP-0066 덕분에 원장당 읽기 용량도 크게 증가했습니다.
더 유용한 호스트 기능이 Soroban에 추가되었습니다: 계약 실행 가능 getter (CAP-0068) 및 문자열/바이트 변환 (CAP-0069).
SCP(Stellar Consensus Protocol) 네트워크 구성은 이제 검증자에 의해 조작될 수 있어 원장 대기 시간을 줄일 수 있는 문이 열립니다. CAP-0070에서 자세히 알아보세요.
아래에서 이러한 각 CAP에 대해 좀 더 자세히 살펴보고, 언제든지 핵심 세부 정보를 확인할 수 있습니다 깃허브. 투표 준비에 대한 모든 관련 정보는 제23 의정서에서 확인할 수 있습니다. 업그레이드 가이드.
CAP-0062: Soroban 라이브 상태 우선순위 지정
CAP-0062는 전체 상태 아카이브의 성능 기능을 소개합니다(자세한 내용은 캡-0057, 현재 초안 형식)을 Live State Prioritization이라고 합니다. 라이브 상태 우선 순위 지정은 보관된 상태와 라이브 상태를 "라이브 상태" 버킷리스트와 "핫 아카이브" 버킷리스트라는 두 개의 별도 데이터베이스로 분리합니다.
Live State BucketList는 현재 BucketList와 유사하며 Stellar "classic" 항목, Live Soroban 항목, 네트워크 구성 설정 등을 포함하여 원장의 모든 라이브 상태를 포함합니다. Hot Archive BucketList는 아카이브된 영구 Soroban 항목을 저장합니다. 유효성 검사기는 두 데이터베이스의 항목을 모두 저장합니다. 현재로서는 유효성 검사기에서 상태 또는 항목이 제거되지 않습니다.
전체 상태 보관 전에 실시간 상태 우선 순위 지정을 구현하면 CAP-0057에 대한 업데이트를 훨씬 더 원활하게 만들고 애플리케이션 중단 가능성을 낮추는 등 상당한 이점이 있습니다.
CAP-0062의 구현은 아래에 설명된 다른 프로토콜 23 CAP 중 두 가지인 CAP-0065 및 CAP-0066에 도입된 것을 포함하여 추가 최적화의 가능성을 열어줍니다.
CAP-0063: 병렬 처리 친화적인 트랜잭션 스케줄링
이 CAP는 트랜잭션 세트에 대한 제한된 실행 시간을 유지하면서 스마트 계약 트랜잭션의 병렬 실행을 허용하는 새로운 트랜잭션 세트 구조를 정의하여 속도와 CPU 효율성을 개선합니다. 또한 TTL 연장 및 수수료 환불 로직을 약간 조정합니다. 더 읽어보기 여기.
현재 검증자는 단일 CPU 코어만 사용하여 주어진 트랜잭션 세트에서 한 번에 하나씩 스마트 계약 트랜잭션을 처리합니다. 이 CAP는 검증자가 여러 스마트 계약 트랜잭션을 동시에 실행하여 여러 CPU 코어에 병렬로 작업을 분산하는 방법을 자세히 설명합니다. Stellar 스마트 계약은 처음부터 병렬 처리를 위해 설계되었습니다(덕분에) CAP-0046: 스마트 계약 데이터), 검증자가 비병렬 트랜잭션 집합보다 병렬 친화적인 트랜잭션 집합을 선택하는 것을 막을 수 있는 것은 없습니다. 이 CAP는 모든 트랜잭션 집합을 예측 가능하게 병렬화할 수 있는 새로운 프로토콜 수준 구조를 도입하여 이러한 예측 불가능성을 해결합니다.
CAP-0065: 재사용 가능한 모듈 캐시
CAP-0065는 재사용 가능한 Wasm 모듈 캐시를 도입하여 배포되고 사용 가능한 모든 Wasm 모듈이 모든 원장에서 항상 메모리에서 구문 분석, 검증 및 변환된 상태로 유지될 수 있도록 합니다.
Wasm 모듈을 실행하기 전에 몇 가지 비용이 많이 드는 단계를 거칩니다.
구문 분석: 바이트 코드를 읽고 구조화된 형식으로 변환
검증: 모듈이 필요한 규칙(예: 메모리 제한, 기능 구조 등)을 준수하는지 확인합니다.
번역 : Wasm을 기본 VM에서 실행 가능한 형식으로 변환
현재 Stellar는 이 작업의 결과를 트랜잭션별로 각 모듈의 캐시에 저장하며, 이는 캐시가 단일 트랜잭션 기간 동안만 존재하고 나중에 폐기됨을 의미합니다. 트랜잭션 집합이나 블록에서 동일한 Wasm 모듈이 반복적으로 사용되더라도 네트워크는 매번 구문 분석, 유효성 검사 및 변환 프로세스를 다시 실행해야 합니다.
이 디자인 결정은 처음에 더 오래 지속되는 캐시를 유지하기 위해 속성을 지정하고 수수료를 부과하는 명확한 방법이 없었기 때문에 내려졌습니다. 그러나 CAP-0062를 통해 Soroban은 인메모리 원장 상태와 디스크 원장 상태를 분할하여 Wasm 모듈 캐시가 실시간 계약만 추적할 수 있도록 합니다. 결과적으로, 캐싱 비용은 이제 컨트랙트가 업로드 또는 복원 작업을 통해 메모리에 들어가는 순간에 직접 연결될 수 있습니다. 거래 실행 중 구문 분석, 검증 및 번역 비용이 없기 때문에 사용자 수수료가 낮아집니다.
CAP-0066: Soroban 메모리 내 읽기 리소스
CAP-0066은 모든 라이브 항목이 유효성 검사기 메모리에 저장되는 인메모리 Soroban 상태를 도입합니다. 이는 스마트 컨트랙트 호출에서 디스크 읽기를 완전히 제거하여 처리량을 크게 개선하고 수수료를 절감합니다. 또한 Soroban 항목의 자동 복원을 소개합니다.
이를 위해 CAP-0066은 인메모리 읽기와 디스크 읽기를 구분하는 Soroban 읽기를 위한 새로운 리소스 유형을 도입했습니다. CAP-0062 덕분에, Soroban의 라이브 상태를 메모리에 완전히 저장할 수 있어 컨트랙트 실행 중 디스크 액세스가 필요하지 않습니다. 모든 상태가 메모리에 저장되기 때문에 더 이상 라이브 Soroban 상태에 대한 읽기 바이트 제한이나 읽기 요금이 없습니다(읽기 항목 제한이 여전히 적용됨).
이 CAP와 관련된 리소스 제한 및 수수료 변경 사항이 있습니다. GitHub에서 자세히 알아보기 여기.
CAP-0066은 또한 InvokeHostFunctionOp를 통해 보관된 Soroban 항목의 자동 복원을 도입합니다. 프로토콜 23 이전에는 개발자가 아카이브된 상태를 다시 사용하기 위해 복원 작업을 명시적으로 호출해야 했습니다. 이제 InvokeHostFunctionOp가 실행될 때마다 네트워크는 자동으로 풋프린트를 확인하고 컨트랙트 실행 전에 필요한 모든 아카이브 항목을 복원합니다. 대부분의 경우 시뮬레이션 또는 프리플라이트를 실행하면 만료된 항목이 감지되어 풋프린트에 포함됩니다. 복원되는 아카이브 항목은 여전히 디스크 기반 데이터처럼 처리되며 임대료, 쓰기 및 읽기 요금이 계속 적용됩니다.
CAP-0067: 통합 자산 이벤트
이 제안된 CAP를 사용하면 내장된 "클래식" 작업이 스마트 계약 트랜잭션 이벤트와 동일한 형식으로 자산 이벤트를 방출할 수 있으므로 스마트 계약 호출과 기본 제공 작업 간의 이벤트 스트림을 통합하고 더 간단한 다운스트림 시스템을 사용할 수 있습니다.
이 CAP에 도입된 주요 변경 사항은 다음과 같습니다.
Stellar Core는 이제 다음과 같이 정의된 대로 Stellar Asset Contract(SAC) 이벤트 형식을 사용하여 모든 Stellar 자산 이동에 대한 이벤트를 방출할 수 있습니다. SEP-0041: Soroban 토큰 인터페이스. SEP-0041 사양 및 SAC 구현에 대한 몇 가지 사소한 업데이트가 있으며, 이에 대한 내용은 GitHub에서 확인할 수 있습니다.
또한 이 CAP는 Soroban에서 멀티플렉스 계정(M 계정) 지원과 이를 수용하기 위한 SAC에 대한 해당 업데이트를 도입합니다. Soroban은 이제 다중화를 지원하기 때문에 거래 메모의 사용은 더 이상 필요하지 않으므로 금지됩니다.
이 CAP를 통해 인프라 운영자는 제네시스 원장에서 시작하는 이벤트를 소급하여 방출할 수 있습니다. 전체 기록을 유지하고 뛰어난 자산 이벤트(예: 인덱서)에 대한 완전한 지원을 원하는 인프라 공급자는 모든 기록 데이터를 다시 수집해야 합니다. 더 알아보기 여기.
CAP-0068: 'address'에 대한 실행 파일을 가져오기 위한 호스트 함수
CAP-0068은 다른 컨트랙트 주소와 연결된 실행 파일을 검색하는 새로운 스마트 컨트랙트 호스트 기능을 제안합니다. 현재로서는 이를 수행할 수 있는 방법이 없기 때문에 계약이 Wasm인지 내장형인지 판단할 수 없으며(현재 유일한 내장 계약은 SAC(Stellar Asset Contract)입니다) 해당 지식을 기반으로 결정을 내리는 것이 불가능합니다.
이 CAP를 사용하면 다음과 같은 몇 가지 중요한 사용 사례를 사용할 수 있습니다.
사용자 지정 계정은 신뢰할 수 있는 계약에 연결된 권한 부여 정책을 적용할 수 있습니다.
컨트랙트는 온체인에서 SAC 인스턴스와 사용자 지정 토큰을 구별할 수 있으며, 이는 컨트랙트 토큰이 SAC의 메타데이터를 가장하는 것을 방지하는 데 도움이 되며, 다른 체인에서 스텔라 토큰을 래핑하는 브리지에 유용합니다.
계약은 종속성의 정확한 구현을 고정할 수 있으며, 이는 업그레이드되거나 신뢰할 수 없는 버전과의 상호 작용을 피할 수 있음을 의미합니다.
CAP-0069: 문자열/바이트 변환 호스트 함수
이 CAP는 문자열과 바이트 유형 간의 변환을 더 쉽게 만드는 두 가지 새로운 Soroban 호스트 함수를 제안합니다. 문자열과 바이트는 내부적으로 비슷하지만, 오늘날 둘 사이를 변환하려면 그렇지 않으면 필요하지 않은 할당자 라이브러리에 연결하는 것과 같은 복잡하고 비효율적인 해결 방법이 필요합니다. 두 개의 새로운 호스트 함수(ByteObject를 StringObject로 변환하는 bytes_to_string와 StringObject를 ByteObject로 변환하는 string_to_bytes)를 제공하면 계약 크기와 복잡성이 줄어듭니다.
CAP-0070: 구성 가능한 SCP 타이밍 매개변수
여러분, 오늘의 마지막 CAP에 도착했습니다! CAP-0070은 Stellar 네트워크가 원장 마감 시간, 지명 및 투표 시간 초과, 라운드별 지명 시간 초과 증분 및 라운드별 투표 시간 초과 증가를 동적으로 조정할 수 있는 원장 구성 설정을 도입합니다. 이를 통해 제어되고 점진적인 개선을 통해 블록 시간 성능을 향상시켜 중단적인 프로토콜 업그레이드 없이 확장성, 복원력 및 효율성을 높일 수 있습니다.
현재 하드코딩된 설정은 성능 향상을 제한하고 네트워크가 점진적으로 더 짧은 블록 시간을 테스트하고 채택하는 것을 방지합니다. 이 CAP를 사용하면 이러한 매개변수를 구성할 수 있으므로 소규모로 점진적으로 성능을 조정할 수 있습니다. 프로토콜 23이 통과되고 네트워크가 업그레이드되면 스텔라 컨센서스 프로토콜(SCP)에 즉각적인 영향은 없지만 향후 변경의 문을 열 것입니다.
다른 주목할 만한 변경 사항
프로토콜 수준의 변경 사항은 아니지만, 프로토콜 23에는 개발자가 알아야 할 몇 가지 추가 업데이트도 도입되었습니다.
출처:stellar.org