최근 트윗에서 XRP Ledger dUNL 유효성 검사기인 Vet은 XRP Ledger의 스마트 계약에 대한 리플 CTODavid Schwartz의 청사진을 설명했습니다.
Schwartz는 리플X 소프트웨어 엔지니어 Mayukha Vadari, Bias Goose, Dan Fisher 등과 함께 X 공간 "XRPL 프로그래밍 가능성"에 대한 토론에 참여했습니다.
Vet은 리플 CTO가 제공한 통찰력을 4가지 사항으로 요약했습니다. 몇 주 전, XRP는 전용 개발 네트워크인 Alpha Net에서 XRP Ledger 스마트 계약 기능을 출시하면서 주요 스마트 계약 이정표에 도달했습니다.
David는 XRP 원장의 스마트 계약에 대해 설명합니다. 1) 완전한 범용 SC가 필요하지 않습니다. 최고의 SC 플랫폼이 될 필요는 없으며 SC를 통한 약간의 프로그래밍 가능성만 있으면 됩니다. 2) 기본 기능을 향상시킵니다. 기본 기능을 함께 연결할 수 없으면 유용하지 않습니다. 3)…사진. 지저귀다. com/WENSRxRJUI.
Vetex는 XRPL의 제한된 스마트 계약에 대한 Schwartz의 이론적 근거를 설명했습니다. 리플 CTO에 따르면 XRP Ledger에는 완전한 범용 스마트 계약이 필요하지 않을 수 있으며 스마트 계약을 통한 약간의 프로그래밍 가능성이 필요할 수 있다고 덧붙였습니다. "우리는 최고의 SC 플랫폼이 될 필요는 없으며 SC를 통한 약간의 프로그래밍 가능성만 있으면 됩니다. "
Schwartz는 스마트 계약이 기본 기능을 향상시키는 시나리오를 구상하고 기본 기능을 함께 연결할 수 없으면 유용하지 않다고 덧붙였습니다.
RippleCTO는 작은 단계의 본질을 강조하면서 안전의 중요성을 거듭 강조했습니다. 이 접근 방식은 완전한 프로그래밍 가능성을 허용하지는 않지만 측정된 단계를 허용하므로 Schwartz는 이것이 최고의 실제 피드백을 제공할 것이라고 믿습니다.
SCs-XLS101은 설계가 제한되어 있으므로 프로토콜 변경이 아닌 대규모 수정이 가능합니다. 이는 은행과 개인 사용자를 모두 포함하여 XRPL을 사용하는 모든 행위자에게 프로토콜 보안이 크게 향상되는 것으로 여겨집니다.
XRP Ledger의 스마트 계약 구현에 대한 논의가 계속되면서 리플X 소프트웨어 엔지니어 Mayukha Vadari는 XLS-101 스마트 계약에 대한 트윗을 통해 알림을 공유합니다.
"알림: XLS-101 스마트 계약은 EVM 기반이 아닙니다"라고 Mayukha는 트윗에 썼습니다. XLS-101 스마트 계약은 이더리움 스마트 계약을 지원하는 독립형 블록체인인 XRPL EVM 사이드체인과 차별화됩니다.
XLS-101 스마트 계약은 XRPL용 스마트 계약 시스템의 공식 설계로, 여러 기존 스마트 계약 시스템(Xahau의 Hooks 및 EVM 포함)에서 영감을 얻었습니다.
보고된 바와 같이, Vet은 이전에 XRPLedger 스마트 계약에 대한 오해를 분명히 밝혔으며, 이는 일부 기존 설계와 정확히 동일하거나 XRPL의 기존 빌딩 블록을 대체하거나 검증자에게 비용을 지불하는 합의 프로토콜을 수정하려는 의도가 아니라는 점을 지적했습니다.
원문 제목: XRP Ledger: Ripple CTO Reveals Blueprint for Advanced Smart Contracts
In a recent tweet, Vet, an XRP Ledger dUNL validator, outlinesRipple CTODavid Schwartz's blueprint for smart contracts on the XRP Ledger.
Schwartz was part of a discussion on X space "Programmability on XRPL," alongside RippleX software engineer Mayukha Vadari, Bias Goose, Dan Fisher and others.
Vet summarized insights offered by the Ripple CTO in four points.
Weeks back, XRP reached a major smart contract milestone with the launch of the XRP Ledger Smart Contracts feature on AlphaNet, a dedicated development network.
David on Smart Contracts on the XRP Ledger.
1) We don't need full general purpose SC.
We don't need to be the best SC platform, just a little bit programmability via SC.
2) It boosts native features.
If you can't connect native features together they are not as useful.
3)…pic.
twitter.
com/WENSRxRJUI.
Vetexplained Schwartz's rationale for limited smart contracts on the XRPL.
According to the Ripple CTO, the XRP Ledger might not need full general purpose smart contracts, adding that it might need just a little bit of programmability via smart contracts: "We don't need to be the best SC platform, just a little bit programmability via SC.
".
Schwartz envisages a scenario where smart contracts boost native features, adding that if they cannot connect native features together, they are not as useful.
TheRippleCTO reiterated the importance of safety, emphasizing the essence of small steps.
This approach will not allow full blown programmability but measured steps, which Schwartz believes will yield the best real world feedback.
Given that SCs-XLS101 is limited in design, it will allow for a large group of amendments to not be protocol changes.
This is believed to be a huge gain in protocol security for all actors using the XRPL, including banks and individual users alike.
As discussions on the smart contract implementation ofXRP Ledgercontinue, RippleX software engineer Mayukha Vadari shares a reminder in a tweet on XLS-101 smart contracts.
"Reminder: XLS-101 smart contracts are not EVM-based," Mayukha wrote in a tweet.
XLS-101 smart contracts are differentiated from the XRPL EVM Sidechain, a standalone blockchain that supports Ethereum smart contracts.
XLS-101 smart contract is a formal design of a smart contract system for the XRPL, which takes inspiration from several existing smart contract systems (including Xahau’s Hooks and the EVM).
As reported, Vet previously clarified misconceptions aboutXRPLedger smart contracts, noting that this is not intended to be exactly the same as some existing design, nor replace XRPL’s existing building blocks, nor modify the consensus protocol that would pay validators.
