코다 편집하기

기업형 블록체인을 [[엔터프라이즈 블록체인]]이라고 하는데, 이를 통해 해결하려고 하는 문제는 [[퍼블릭 블록체인]]으로 해결되는 문제와 분명한 연관성은 있지만 매우 다르다. R3가 코다를 통해 결국 이루려고 하는 것은 “내가 보는 정보가 곧 네가 보는 정보임을 확실히 안다”는 것을 기술적으로 가능하게 하여 좀 더 효율적인 기업운영을 가능하게 하는 것이다. 즉, 한 기업이 거래하고 있는 파트너들과 완벽하게 동기화 된 정보를 갖고 있고, 이러한 사실을 인지함으로써 주어지는 새로운 기회를 포착하는 것이다. “내가 보는 정보가 곧 네가 보는 정보임을 확실히 안다”는 것은 물론 기존에도 가능했다. 하지만 “나”와 “너” 사이에는 항상 정보를 동기화해주는 중개자가 있어왔다.<ref name="코다1">블록체인 코다(Corda), 〈[https://medium.com/@cordakorea/%EC%9A%B0%EB%A6%AC%EB%8A%94-%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8-%EC%BD%94%EB%8B%A4-corda-%EB%A1%9C-%EC%96%B4%EB%96%A4-%EB%AC%B8%EC%A0%9C%EB%A5%BC-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B3%A0%EC%9E%90-%ED%95%98%EB%8A%94%EA%B0%80-327dabd4f8 우리는 블록체인 코다(Corda)로 어떤 문제를 해결하고자 하는가?]〉, 《미디엄》, 2018-07-01</ref> 중앙에서 관리감독 하는 기관 없이 참가자들이 자신의 [[컴퓨터]]만 보고 “내가 보는 것이 곧 네가 보는 것”이라는 것을 처음 알 수 있도록 한 것은 퍼블릭 블록체인의 근본적인 기술혁신 중 하나이다. 이것이 비트코인의 탄생에 있어 가장 획기적인 기술 중 하나라는 것은 누구도 부정할 수 없는 사실이며 기존의 비즈니스 프로세스에 존재했던 높은 비용, 복제, 낭비 및 오류 위험을 없앨 수 있는 열쇠였다. 물론 퍼블릭 블록체인에 대한 매우 긍정적인 전망이 다음 [[크립토키티]](Cryptokitties)를 발명하여 수십억 달러를 버는 것보다는 훨씬 시시하겠지만 그렇다고 흥미롭지 않은 것 또한 아니다.<ref name="코다1"></ref>

예를 들어 [[금리스왑]](IRS)에 블록체인을 적용했다고 생각해보자. 만약 당사자의 기록이 거래상대방의 기록과 동일할 뿐만 아니라 모든 이벤트(변동금리 정산 등)가 사전에 합의된 담보약정(CSA)과 스왑 파생상품 계약(ISDA Agreement)에 따라 모든 참가자들에 의해 동일하게 수신되고 처리된다는 것을 확신할 수 있다면 금융 산업은 훨씬 더 큰 발전을 이룰 것이다. 또한 이러한 과정에서 발생하는 비용 절감 효과 또한 상당할 것이다. 현재 모든 은행의 시스템은 각자가 다른 방식으로, 다른 가정 하에 작동하고 서로 다른 [[버그]]를 가지고 있다. 당사자와 거래상대방이 가지고 있는 기록이 항상 동기화되어 있다는 것에 대한 확신을 가질 수 있다면 이를 통해 은행의 거래방식에도 커다란 진전이 생길 것이다.<ref name="코다1"></ref> 금융을 참가자들 간의 계약으로 보면 금융 산업에서의 블록체인에 대한 기회는 분명해지며 이를 통해 계약을 기록하고 관리하며 자동화하는 것으로 많은 비용을 절감할 수 있어 결과적으로 새로운 비즈니스 기회를 창출할 수 있을 것이다.<ref name="코다1"></ref>

코다 네트워크는 사전에 협의된 노드끼리의 통신망이다. 각각의 노드는 [[Java EVM]] 환경에서 구동되는 코다 서비스와 [[코댑]](CorDapps)라고 불리는 코다의 자체적인 [[디앱]]을 구동할 수 있다. 노드 간의 통신은 직접 연결되며, 미들웨어의 메시지를 전달할 때 표준 [[프로토콜]]로 사용되는 [[AMQP]](Advanced Message Queuing Protocol) 1.0을 활용한다.<ref>레드햇 공식 홈페이지 - https://www.redhat.com/ko/technologies/jboss-middleware/amq</ref> 이 과정에서 메시지를 [[TLS]] 암호화하여 전송하기 때문에 모든 메시지는 이해관계자끼리만 공유되며 네트워크 전체에 메시지를 전파하지 않는다. 각각의 네트워크는 [[네트워크 맵 서비스]](Network Map Service)를 지원하는데, 이는 네트워크상에 있는 노드와 통신할 수 있도록 모든 노드에 [[IP]] 주소를 부여하는 서비스이다. 네트워크 맵 서비스는 일종의 전화번호부 역할을 수행한다고 생각하면 되는데, 노드의 신원을 보증하는 역할 역시 네트워크 맵 서비스가 도맡는다. 이 서비스에는 네트워크상의 모든 노드에 연락할 수 있는 정보가 담겨있어 메시지를 받는 노드가 [[오프라인]] 상태라면 대기하고 있다가 [[온라인]]이 되면 메시지가 전달된다. 따라서 모든 메시지는 수신자를 명시해야 하며 발신자는 수신자와 수신자가 보게 될 내용을 모두 컨트롤 할 수 있다.<ref name="박진형"></ref>

이 두 가지의 신원을 입증한 후 코다의 분산 네트워크에서 하나의 노드가 여러 개의 네트워크에 참여할 수 있게 된다. 코다에 참여하는 모든 노드는 자신이 인증한 신원이 Composite Keys에 올라가게 되며 이는 서비스에 실제로 참여하고 있는 노드의 서명값을 모아둔 것이다. Composite Keys에 올라가게 되었다고 해서 자신의 신원이 모든 노드에게 공개되었다는 것은 아니다. 네트워크상에서 자기 자신을 숨길 수도 있는데 이는 자신이 처음 네트워크에 가입했을 때 어떤 종류로 참여했느냐에 따라 달라진다. 자신의 네트워크 신원은 [[X.509]] 인증서에 담긴다. 신원을 모두 공개하는 노드는 법적인 효력이 있는 서비스를 활용할 수 있는 [[공개키]]를 부여받게 되어 해당 노드에게 발급되는 인증서는 누구나 열람할 수 있다. 즉, 해당 노드의 존재 사실을 모든 노드가 확인할 수 있게 되어 자신의 신원을 숨기고 비밀통신을 해야 하는 경우에는 적합하지 않다. 반면 비밀노드는 자신의 신원을 꼭 확인해야 하는 상대 노드에게만 자신의 신분을 밝힐 수 있다. 해당 노드의 공개키는 검증인 노드 같은 제3자에게는 보여질 수 있지만 노드의 이름과 X.509 인증서 제공은 철저하게 비공개된다. 설령 제3자가 암호화되지 않은 [[트랜잭션]]에 접근한다고 하더라도 비밀노드에 대한 추가적인 정보가 주어지지 않는다면 해당 트랜잭션의 수신자 혹은 발신자에 대한 정보를 알 수 없다.<ref name="박진형"></ref>

원장을 업데이트하기 전에 트랜잭션은 거래 참여자가 모두 서명을 하는 커밋(commit) 과정을 거쳐야 한다. 전자서명은 아웃풋 상태의 비가역성을 강제하고 이미 커밋 된 트랜잭션의 아웃풋 상태를 변경하기 위한 시도는 트랜잭션에 추가된 [[전자서명]]을 확인하여 쉽게 감지될 수 있다. 새로운 트랜잭션은 이전 트랜잭션의 [[해시]]를 참조하여 비가역성을 지니는 [[체인]]과 같은 구조로 만들어진다.<ref name="야옹메롱"></ref> 이더리움 및 IBM의 [[하이퍼레저 패브릭]](Hyperledger Fabric)과 코다의 차이점은 트랜잭션은 원장을 업데이트하는 행위를 위한 지시가 아니라는 점이다. 이더리움이나 하이퍼레저 패브릭에서 원장을 업데이트하기 위해서는 각 피어들이 원장의 새 상태를 계산하는 코드를 작성해야 한다. 각각의 피어는 원장의 새로운 상태를 계산하기 위해 지시를 내리고, 원장이 업데이트되기 전에 각 피어의 결과 값을 비교한다. 트랜잭션은 코다에서 검증을 필요로 하는 제안이다. 거래의 제안자가 먼저 원장의 새로운 상태를 제안하고, 제안된 원장의 상태가 관련 있는 피어에게 전달한다.<ref name="야옹메롱"></ref> 이후 피어가 계약코드를 통해 거래의 유효성을 검증한 후 서명하여 원장을 업데이트한다.<ref name="야옹메롱"></ref> 코다에서는 트랜잭션 제안자가 아웃풋 상태를 반영하는 업데이트된 원장을 계산하는데 이는 곧 아웃풋 상태들이 업데이트된 원장임을 의미한다.<ref name="백종찬3"></ref>

검증인 노드는 유일성을 검증해주는 노드로 주어진 트랜잭션에 대하여 다른 트랜잭션이 이루어지지 않았다는 사실을 보증하는 역할을 한다. 즉 다른 트랜잭션에서 특정 트랜잭션의 입력상태가 아직 소비되지 않았다는 것을 검증하는데 어떠한 트랜잭션을 검증해달라는 요청을 받은 검증인 노드는 두 가지 역할을 수행한다. 첫 번째, 만약 다른 트랜잭션이 요청을 받은 트랜잭션의 입력 상태를 소비하지 않은 경우 트랜잭션에서 소비한다. 두 번째, 만약 이중지불을 하려는 시도가 감지된 경우 트랜잭션을 파기한다. 이러한 과정을 통해 검증인 노드는 시스템 전반의 완결성을 보장하며 검증인의 서명이 포함되기 전까지 트랜잭션은 유효하다고 볼 수 없다. 만약 충돌되는 두 개의 트랜잭션이 동시에 존재할 경우 검증인 노드가 어느 하나의 트랜잭션이 유효하다는 평가를 내리기 전까지 해당 트랜잭션들은 승인되지 않는다. 반대로 검증인 노드의 서명이 포함된 경우 해당 트랜잭션의 입력 값이 이전 트랜잭션에 의해 소비되지 않았다는 것 또한 증명할 수 있다. 따라서 검증인 제도는 시스템 전체의 완결성을 보장해주고 모든 상태는 검증인이 있어야 하며 검증인은 자신이 맡은 트랜잭션의 검증인인 경우에만 해당 트랜잭션을 검증하는 역할을 하게 된다.<ref name="박진형"></ref>