https://cexplorer.io/article/understanding-the-composability-of-applications-on-cardano
Cardano는 2계층 아키텍처를 통해 애플리케이션의 구성성을 지원하지만 주로 스마트 계약에 대한 모듈식 접근 방식을 통해 지원합니다. 자세한 내용을 읽어보세요. 이 기사에서는 확장성과 병렬성에 대해서도 자세히 알아봅니다. 결론적으로, 구성 가능성과 관련하여 Cardano와 Ethereum을 빠르게 비교할 것입니다.
구성성이란 무엇입니까?
구성 가능성은 서로 다른 애플리케이션이나 구성 요소가 함께 작동하고 서로를 기반으로 구축되어 새롭고 더 복잡한 기능을 생성하는 능력을 나타내는 용어입니다. 결합성은 종종 분산형 애플리케이션(DApp), 특히 사용자가 다양한 프로토콜이나 서비스를 결합하여 새로운 금융 상품이나 시장을 만들 수 있는 분산형 금융(DeFi) 분야에서 바람직한 기능으로 간주됩니다.
구성 가능성을 통해 타사 개발자는 애플리케이션을 연결하고 새로운 솔루션을 시장에 출시할 수 있습니다. 두 개 이상의 애플리케이션을 함께 결합하면 사용자가 단일 인터페이스를 통해 모든 서비스와 상호 작용할 수 있습니다. 단일 애플리케이션 인터페이스를 통해 구성된 모든 애플리케이션의 모든 서비스에 액세스할 수 있습니다.
예를 들어 DEX와 대출 플랫폼을 구성할 수 있습니다. 또는 두 개의 DEX를 함께 구성할 수도 있습니다.
따라서 사용자는 더 많은 풀, 더 많은 토큰, 더 많은 유동성 등에 액세스할 수 있습니다. DEX는 토큰(오라클)의 주문 및 시장 가치 등을 공유할 수 있습니다. 이를 통해 효율성, 수익성 및 사용자 만족도가 향상됩니다.
아래 이미지에서는 두 DEX 팀이 협력하기로 합의하고 애플리케이션을 함께 구성한 것을 볼 수 있습니다. 사용자는 모든 DEX의 단일 인터페이스를 통해 두 DEX의 유동성 풀에 액세스할 수 있습니다.
구성성에도 단점이 있습니다. 애플리케이션을 구성함으로써 상호 의존성이 생성됩니다.
구성 가능성은 인터페이스, 데이터 유형 또는 프로토콜이 다를 수 있는 다양한 애플리케이션이나 구성 요소 간에 더 많은 조정과 동기화가 필요하므로 복잡성을 초래합니다.
구성 가능성은 애플리케이션이나 구성 요소를 충돌, 오류, 공격 또는 취약성과 같은 서로의 더 많은 위험이나 위협에 노출시키므로 보안을 저하시킬 수 있습니다. 한 앱이 해킹되면 다른 앱에 문제가 발생할 수 있습니다.
DeFi 서비스는 경제적으로 상호 연결되어 있다는 점에 유의해야 합니다. 예를 들어, 대출 플랫폼은 다른 애플리케이션에서 발행한 스테이블코인을 사용할 수 있습니다. 어떤 이유로 스테이블코인의 고정이 해제되면 대출 플랫폼 사용자가 영향을 받게 됩니다.
위험에도 불구하고 구성 가능성은 사용자 경험을 개선하고 혁신을 지원하므로 바람직한 기능입니다.
Cardano는 다음을 통해 DApp의 구성성을 가능하게 합니다.
충돌이나 실패를 일으키지 않고 다양한 스마트 계약이나 체인에서 데이터와 가치를 공유합니다.
서로 영향을 주거나 영향을 받지 않고 여러 스마트 계약을 병렬로 실행(실행)합니다.
Ethereum 또는 Bitcoin과 같은 다른 플랫폼 또는 프로토콜과 연결 및 상호 운용됩니다.
Cardano는 원장 수준, 즉 스마트 계약의 병렬 실행을 허용하는 확장된 UTXO 모델을 통해 DApp(또는 애플리케이션)의 구성성을 지원합니다. Cardano는 결제 계층이 가치 이전을 처리하고 계산 계층이 스마트 계약 실행을 처리하는 2계층 아키텍처를 갖도록 설계되었습니다. 또한 스마트 계약의 기능은 온체인 로직과 오프체인 로직으로 나눌 수 있습니다.
Cardano의 2계층 아키텍처
결합성을 제대로 이해하려면 카르다노의 2계층 아키텍처와 스마트 계약의 행위 결과가 원장에 저장되는 방식을 이해하는 것이 중요하다.
스마트 계약 실행(실행 위치에 관계없이)과 결과를 원장에 영구 저장하는 것 사이에는 연관성이 있습니다. 블록체인 플랫폼의 거의 모든 단일 구성 요소는 구성 가능성의 전반적인 품질(또한 확장성, 보안 등)에 영향을 미칩니다.
Cardano는 플랫폼의 핵심 기능을 Cardano Settlement Layer(CSL)와 Cardano Computation Layer(CCL)의 두 가지 레이어로 분리하는 새로운 디자인을 사용하여 다른 플랫폼보다 더 높은 확장성, 보안 및 지속 가능성을 제공하는 것을 목표로 합니다. 이 디자인은 구성 가능성에 일정한 영향을 미칩니다.
CSL은 사용자 또는 스마트 계약 간 ADA 또는 기타 기본 토큰과 같은 가치 이전을 처리하는 역할을 담당합니다. CSL은 확장된 UTXO 모델을 기반으로 하여 트랜잭션이 결정적이고 예측 가능하도록 보장합니다. 중요한 것은 스마트 계약의 병렬 실행이 가능하다는 것입니다.
Ouroboros 지분 증명 합의는 CSL에서 구현됩니다.
CCL은 애플리케이션의 논리와 규칙을 정의하는 Plutus 또는 Marlowe 스크립트(검증기 스크립트, 발행 정책 등)와 같은 스마트 계약의 실행을 처리하는 일을 담당합니다. CCL은 CVM(Cardano Virtual Machine)에서 실행되는 Plutus Core라는 기능적 프로그래밍 언어를 기반으로 합니다.
CCL은 Plutus, Marlowe, Glow, Aiken 등과 같은 여러 프로그래밍 언어를 지원하며, 이는 Plutus Core로 컴파일되어 CVM에서 실행될 수 있습니다.
Cardano의 2계층 아키텍처는 Ethereum과 같은 단일 계층 아키텍처를 사용하는 다른 플랫폼에 비해 몇 가지 장점이 있습니다.
2계층 아키텍처를 사용하면 각 계층을 다른 계층에 영향을 주지 않고 독립적으로 업데이트하고 수정할 수 있으므로 더 많은 유연성과 혁신이 가능합니다. 예를 들어 CSL은 CCL에 영향을 주지 않고 합의 프로토콜이나 토큰 모델을 변경할 수 있습니다. 마찬가지로 CCL은 CSL에 영향을 주지 않고 스마트 계약 언어나 실행 환경을 변경(또는 업그레이드)할 수 있습니다.
반면에 이 아키텍처는 서로 다른 계층 간에 더 많은 조정과 동기화가 필요하므로 복잡성을 가져오고 유용성을 감소시킵니다. 예를 들어 CSL과 CCL은 원장 상태에 대한 일관된 보기를 유지하고 트랜잭션이 두 계층 모두에서 유효하고 호환되는지 확인해야 합니다. 사용성이 떨어지면 사용자나 개발자가 다양한 레이어에 액세스하거나 상호 작용하려면 더 많은 단계와 도구가 필요합니다.
2계층 아키텍처는 블록체인의 부하를 줄이고 스마트 계약의 병렬 실행을 허용하므로 플랫폼의 확장성을 향상시킵니다. 예를 들어, CSL은 스마트 계약 실행이 아닌 가치 이전과 관련된 거래만 검증하면 됩니다. 마찬가지로 CCL은 서로 간섭하지 않고 여러 사이드체인에서 여러 스마트 계약을 병렬로 실행할 수 있습니다.
Cardano의 2계층 아키텍처는 블록체인에서 서로 상호 작용하고 협력할 수 있도록 함으로써 스마트 계약의 구성성을 가능하게 합니다.
스마트 계약(민팅 정책)에 의해 발행된 토큰 A와 B를 통해 발행된 토큰 B를 상상해 보세요. 스왑을 구현하는 또 다른 스마트 계약은 A 토큰과 B 토큰을 모두 사용할 수 있습니다. 이 경우 스마트 계약은 서로 직접 상호 작용하지 않지만(구성되지 않음) 서로 다른 스마트 계약 간에 토큰이 공유됩니다. 자산 수준에서 구성성에 대해 이야기할 수 있습니다.
Cardano는 주로 스마트 계약에 대한 모듈식 접근 방식을 통해 구성성을 허용합니다. 즉, 스마트 계약을 온체인 로직과 오프체인 로직으로 분할하는 것입니다. 이에 대해서는 나중에 더 자세히 이야기하겠습니다.
Plutus 스크립트(검증기)는 CCL의 Cardano 가상 머신에 의해 실행됩니다. CCL은 사용자 또는 스마트 계약 간 ADA 또는 기타 기본 토큰과 같은 가치 전송만 처리하는 계층인 CSL과 상호 작용합니다. CSL은 블록체인의 가치 이전과 관련된 거래를 검증하고 저장합니다.
CSL은 스마트 계약의 출력(부울 값 True 또는 False)에만 작동합니다. 반환 값이 True인 경우 자산은 주소(스크립트 주소)에서만 소비(잠금 해제)될 수 있습니다. CSL은 스마트 계약 자체를 실행하거나 검증하지 않고 CCL에 의해 실행되고 검증되었는지 여부와 반환 값만 확인합니다. CSL은 부울 값을 기반으로 트랜잭션을 수락하거나 거부합니다.
아래 그림에서 CSL과 CCL을 볼 수 있습니다. 또한, 온체인 로직과 오프체인 로직으로 구분되는 스마트 계약입니다. 온체인 로직은 CVM에 의해 실행되는 반면, 오프체인 로직은 서버나 사용자의 로컬 컴퓨터에서 실행될 수 있습니다. 유효성 검사기 스크립트의 반환 값이 True이면 트랜잭션이 CSL의 원장에 기록됩니다.
많은 애플리케이션(Plutus 스크립트)이 CSL을 병렬로 사용할 수 있습니다. UTXO 모델은 거래가 결정적이고 예측 가능하며 원장이나 다른 거래의 글로벌 상태에 의존하지 않도록 보장합니다. 따라서 동일한 UTXO를 사용하지 않는 한 서로 간섭하지 않고 서로 다른 트랜잭션이나 스마트 계약을 병렬로 실행할 수 있습니다.
UTxO 모델의 병렬성은 스마트 계약이 충돌이나 실패를 일으키지 않고 블록체인에서 서로 상호 작용하고 협력할 수 있게 해주기 때문에 결합성에 도움이 됩니다. 예를 들어, 토큰을 구현하는 스마트 계약은 스왑, 대출 플랫폼 또는 경매를 구현하는 다른 스마트 계약에서 사용될 수 있습니다. UTxO 모델은 충돌이나 실패를 일으키지 않고 이러한 트랜잭션을 병렬로 처리할 수 있습니다.
스마트 계약에 대한 모듈식 접근 방식
Cardano는 스마트 계약이 온체인 코드와 오프체인 코드라는 두 가지 구성 요소로 구성된 모듈식 접근 방식을 사용합니다. Cardano는 스마트 계약의 온체인 및 오프체인 부분을 통해 애플리케이션의 구성성을 허용합니다. Cardano에서 스마트 계약이 작동하는 방식에 대해 자세히 알아보려면 이 주제에 대한 기사를 읽어보세요. 비트코인과 이더리움에 관한 장을 건너뛸 수 있습니다.
온체인 코드는 스마트 계약과 관련된 거래를 검증하기 위해 블록체인(CCL)에서 실행되는 스크립트입니다. 일반적으로 스크립트 주소에서 자금을 잠금 해제하는 간단한 코드입니다.
오프체인 코드는 스마트 계약 논리를 준수하는 트랜잭션(스크립트를 사용한 트랜잭션과 지출 트랜잭션 모두)을 생성하기 위해 사용자의 컴퓨터나 서버에서 실행되는 복잡한 애플리케이션일 수 있습니다. 이는 엄청난 유연성을 제공하지만 복잡성이 높을수록 위험이 따릅니다. 이는 예를 들어 스마트 계약의 논리를 실행하려면 여러 실행 환경(예: 서버의 Java Virtual Machine 및 블록체인의 Cardano Virtual Machine)을 사용해야 한다는 사실에서 비롯됩니다. CCL).
모듈식 접근 방식을 사용하면 대부분의 스마트 계약 논리가 오프체인에서 실행되어 블록체인의 부하와 비용이 줄어들기 때문에 효율성과 확장성이 향상됩니다. Plutus 스크립트(검증기) 수준의 구성 가능성은 가능하지만 오프체인 논리 수준의 구성 가능성만큼 간단하지는 않습니다.
Plutus 스크립트 수준의 구성 가능성은 스마트 계약의 다양한 온체인 부분이 블록체인(CCL)에서 서로 상호 작용하고 협력하여 새롭고 더 복잡한 기능을 생성할 수 있음을 의미합니다. 이 접근 방식은 일반적으로 문제가 있으므로 개발자는 기피합니다. 서로 다른 스마트 계약에는 서로 다른 인터페이스, 데이터 유형 또는 프로토콜이 있을 수 있으며, 이로 인해 서로 호환되지 않거나 일관되지 않을 수 있습니다. 접근 방식의 표준화와 통합은 개발자가 구성성을 달성하는 데 도움이 될 수 있습니다.
서로 다른 스마트 계약에는 서로 다른 상태, 종속성 또는 제약 조건이 있을 수 있으므로 서로 조정하거나 동기화하는 것이 어렵거나 불가능할 수 있습니다. 유효성 검사기 스크립트 수준에서 구성성을 달성하려면 스마트 계약은 상태, 종속성 또는 제약 조건을 전달하고 조정하는 일부 메커니즘이나 기술을 사용해야 합니다. 그러나 이를 위해서는 애플리케이션 개발 초기 또는 나중에 유효성 검사기를 다시 구현할 때 팀의 협력이 필요할 가능성이 높습니다.
다행스럽게도 애플리케이션(스마트 계약)이 검증자(온체인 로직) 수준에서 상호 작용할 필요는 없습니다. 오프체인 로직 수준에서는 훨씬 간단합니다.
오프체인 로직을 설계할 때 개발자는 온체인 로직의 요구 사항에 따라 최소한의 제한만 받습니다. 본질적으로 구성성을 염두에 두고 기능을 설계할 수 있습니다.
개발자는 프로그래밍 언어, 프레임워크 또는 기존 표준을 사용하여 스마트 계약의 오프체인 부분을 생성할 수 있습니다. 그들이 보장해야 할 유일한 것은 Cardano 노드 API와의 상호 작용입니다.
다양한 오프체인 애플리케이션은 다른 오프체인 애플리케이션에 영향을 주지 않고 서로 자유롭게 상호 작용할 수 있습니다. 이 수준에서 앱을 연결하는 것은 매우 쉽고 일반 개발자에게는 큰 도전이 아닙니다.
애플리케이션의 오프체인 부분의 상호작용 결과는 온체인 부분에 반영됩니다. 결국 그 결과는 검증자를 거쳐 원장에 기록되어야 한다. 즉, 애플리케이션 간의 오프체인 상호작용은 검증인이 잠긴 자금을 잠금 해제하는 지출 거래의 구성으로 이어져야 합니다.
애플리케이션의 확장성과 계산 복잡성은 스마트 계약의 오프체인 부분 수준에서 거의 무제한이라고 할 수 있습니다. 병목 현상은 블록 크기입니다.
CSL은 트랜잭션의 병렬 처리를 가능하게 합니다(UTxO 모델). CCL은 스마트 계약의 병렬 실행을 가능하게 합니다. 스마트 계약의 병렬 실행은 서로 다른 스마트 계약이 동일한 UTxO와 상호 작용하지 않는 한 서로 영향을 미치거나 영향을 받지 않고 병렬로 실행될 수 있음을 의미합니다. 스마트 계약의 온체인 부분 출력이 True인 경우 트랜잭션을 블록체인에 저장해야 합니다. 즉, 다음 블록으로 가져와야 합니다.
아래 이미지에서는 스마트 계약의 두 오프체인 부분이 어떻게 서로 통신하는지 볼 수 있습니다(녹색 화살표). 그림에서 애플리케이션의 오프체인 부분은 의도적으로 더 크며, 이는 더 복잡한 로직이 거기에 구현되어 있음을 나타냅니다. 스마트 계약의 온체인 부분도 서로 통신할 수 있습니다(빨간색 화살표). 그림은 또한 스마트 계약 간의 상호 작용 결과로 원장에 기록되는 두 개의 지출 거래가 어떻게 생성되는지 보여줍니다(파란색 화살표). 지출 거래를 통해 스크립트 주소에 자금이 잠금 해제되었습니다(스크립트를 사용한 거래는 이미 원장에 저장되어 있습니다).
DeFi 빌더는 Cardano에서 구성 가능한 애플리케이션을 만들 수 있습니다. 그러나 완전한 구성성을 달성하려면 해결해야 할 몇 가지 과제와 제한 사항도 있습니다.
스마트 계약 언어 및 인터페이스의 호환성 및 표준화.
애플리케이션의 유용성 및 접근성. 사용자는 다양한 애플리케이션에 액세스하기 위해 여러 개의 지갑이나 계정이 필요할 수 있습니다.
결론
Ethereum이 사용하는 스마트 계약에 대한 모놀리식 접근 방식은 보안과 단순성 측면에서 장점이 있지만 확장성과 유연성 측면에서는 단점이 있습니다. Cardano는 스마트 계약에 모듈식 접근 방식을 사용합니다. 확장성과 유연성 측면에서는 장점이 있지만 보안성과 복잡성 측면에서는 단점이 있습니다.
모놀리식 접근 방식은 높은 수수료와 혼잡으로 이어질 수 있으며, 이는 스마트 계약의 성능과 유용성을 저해할 수 있습니다. 모든 계약의 기능은 분산 네트워크의 계산 리소스를 소비합니다. 오프체인 기능의 일부를 수행하는 것은 불가능합니다. 애플리케이션은 플랫폼이 제공하는 기능에 따라 제한되기 때문에 유연성이 떨어집니다. 반면에 애플리케이션이 (상대적으로) 간단하기 때문에 이점이 될 수도 있습니다. 스마트 계약의 모든 기능은 Solidity(또는 Vyper)로 작성되었습니다. 이는 모든 거래와 스마트 계약이 동일한 합의 메커니즘에 의해 검증되고 동일한 가상 머신에 의해 실행되므로 보안 관점에서도 유리합니다.
제 생각에는 이더리움의 가장 큰 단점은 스마트 계약을 순차적으로 실행해야 한다는 것입니다. 이러한 제한은 계정 기반 모델 사용으로 인해 발생합니다.
모듈식 접근 방식은 다양한 모듈이나 레이어가 다양한 작업을 병렬 또는 비동기식으로 처리할 수 있으므로 더 높은 확장성을 달성할 수 있습니다. 이를 통해 네트워크 부하를 줄일 수 있으며 분산된 컴퓨팅 리소스가 덜 소비되므로 사용자는 더 낮은 수수료를 지불할 수 있습니다. 모듈식 접근 방식을 통해 더욱 복잡하고 다양한 스마트 계약을 생성할 수 있습니다. 그러나 모듈이나 레이어에 따라 신뢰 및 검증 수준이 다를 수 있으므로 보안 위험이 발생할 수 있습니다. 개발자를 위한 더 높은 유연성과 무제한 옵션은 복잡성을 야기하여 블록체인의 데이터와 논리에 취약성과 불일치를 초래할 수 있습니다.
카르다노의 가장 큰 단점은 아마도 낮은 표준화와 통일성일 것이다. 현재 표준 구현과 관련된 여러 CIP가 있습니다. 이는 부분적으로 Cardano가 아직 초기 단계의 플랫폼이기 때문입니다.
다음 기사에서는 Cardano와 Ethereum의 애플리케이션 구성성을 더 자세히 비교해 보겠습니다.