플라즈마 리뷰

Minimal Viable Plasma and Plasma Cash

Published in

해시드 팀 블로그

19 min readSep 12, 2018

이번에 해시드 내부에서 공부했던 내용과 함께 논의한 내용들을 정리된 글로 나눌 수 있는 기회가 생겨서, 플라즈마 기술에 대한 리뷰를 시작으로 블록체인 기술에 대한 리뷰나 여러 아이디어들을 찬찬히 적어보려 합니다. 내용에 대한 피드백은 언제나 감사히 받겠습니다.

본 리뷰 글에서는 가장 많이 언급되고 있는 이더리움 확장성 솔루션 중 하나인 플라즈마에 대한 간략한 설명을 시작으로, Minimal Viable Plasma(MVP), 플라즈마 캐시, 그리고 그 이외에 논의되고 있는 기법들에 대해 다루겠습니다.

플라즈마란?

플라즈마(Plasma)는 조셉 푼(Joseph Poon)과 비탈릭 부테린(Vitalik Buterin)이 함께 제시한 이더리움 확장성 솔루션이다. 2017년 8월에 작성된 백서(Plasma: Scalable Autonomous Smart Contracts[1])에서는 플라즈마의 기본적인 개념과 더불어 오류검증(fraud proof), 맵리듀스(MapReduce), 예치(deposit) 절차, 루트체인 승인(root chain commitment) 절차, 단순 인출(withdrawal) 및 대량 인출 절차 등을 다루고 있다.

간략하게 소개하자면 플라즈마는 이더리움 메인넷을 부모 체인(parent chain)으로 보고 이에 종속되는 자식 체인(child chain)을 생성하여, 기존에 이더리움 메인넷에서만 발생하던 트랜잭션을 자식 체인에서도 생성할 수 있게 함으로써 이더리움 네트워크 전체의 단위 시간당 트랜잭션 처리량을 증가시킬 수 있다는 개념이다. 이를 활용하면 단순하게는 이더리움 메인넷을 부모 체인으로 하는 다수의 자식 체인을 생성할 수도 있지만, 자식 체인들이 또 다른 손자/손녀 체인들의 부모 체인이 되는 계층적(hierarchical)인 구조로 반복적으로 확장이 가능하기에 이론적으로는 단위 시간당 트랜잭션 처리량을 무한히 향상시킬 수 있다. 물론 플라즈마 체인 간 자금의 이동에는 긴 시간이 소요되고, 깊은 계층에서 생성된 트랜잭션은 확정까지 걸리는 시간이 오래 걸리는 등, 무한한 확장성은 아직까지는 현실적이지 않다.

플라즈마 백서에는 앞서 설명한 기본적인 개념뿐만 아니라 플라즈마를 사용하는 이용자들에게 제공되어야 할 여러 절차들이 명시되어 있다. 구체적으로, 새로운 이용자가 플라즈마의 자식 체인에 참가하기 위해서 부모 체인의 플라즈마 컨트랙트로 예치금(deposit)을 보내고 그 양에 해당하는 코인이 자식 체인 상에서 발행되는 과정, 반대로 자식 체인에서 빠져나오기 위해서 인출(withdrawal) 절차를 통해 일정 시간동안 자식 체인에서 가지고 있는 코인을 확인받은 후 플라즈마 컨트랙트에서 해당량의 코인을 돌려받게 되는 과정 등이 다루어진다. 뿐만 아니라 자식 체인에서 적용 가능한 PoS 기반 합의 알고리즘, 계층적인 구조를 활용하여 맵리듀스를 통한 향상된 연산력을 지원하는 법 등이 제시되어 있다.

플라즈마 백서에 대한 자세한 설명에 대해서는 이미 좋은 자료들이 많이 공개되어 있다. 이들을 함께 읽어보는 것을 추천한다.

Minimal Viable Plasma(MVP)

2018년 1월, 가능한 단순화된 플라즈마의 개발을 위해 기본적인 보안성만을 제공하는 Minimal Viable Plasma(MVP)[6]가 제시되었다.

MVP는 크게 세 가지 요소로 나누어 볼 수 있다. 우선 이더리움 메인넷에는 플라즈마 체인의 관리를 담당하는 플라즈마 컨트랙트(plasma contract)가 위치하고, 플라즈마 체인에서는 플라즈마 블록을 생성하고 머클 루트(Merkle root) 값을 메인넷으로 지속적으로 전송하는 오퍼레이터가 있으며, 이 플라즈마 체인을 이용하여 트랜잭션을 발생시키려는 유저들이 있다.

일반적인 사이드체인을 이용한 인터체인 확장성 솔루션과 플라즈마를 구분 짓는 가장 큰 핵심은 메인넷과 사이드체인 사이의 연결 관계이다. 일반적인 인터체인 솔루션에서는 메인넷과 사이드체인이 비교적 동등한 관계에서 교류가 일어나며, 각각의 체인이 그 자체로 충분한 안전성을 제공해야 한다. 반면 플라즈마에서는 메인넷의 플라즈마 컨트랙트를 통하여 플라즈마 체인이 메인넷에 종속된 형태를 가지며, 플라즈마 체인의 안전성은 메인넷에 의존적이다. 새로운 플라즈마 블록이 생성될 때는 이 플라즈마 체인에 참여하고 있는 노드들과 플라즈마 블록을 공유하지만, 메인넷에는 블록의 루트 값만을 플라즈마 컨트랙트에 저장한다. 따라서 플라즈마 체인의 일종의 압축된 정보만이 메인넷에 저장되기 때문에 1) 메인넷 단독으로 존재할 때와 비교하여 더 많은 수의 트랜잭션을 병렬적으로 처리할 수 있고, 2) 메인넷 사용 비용 절감의 효과를 얻을 수 있으며, 3) 단일 오퍼레이터가 블록 생성 권한을 가지면서 발생할 수 있는 악의적인 행동을 메인넷에서 사후 검증할 수 있게 된다.

플라즈마 컨트랙트는 메인넷에서 플라즈마 체인을 관리하는 역할을 하며, MVP에서는 기본적으로 다음의 함수들이 담겨있다.

submitBlock: 오퍼레이터가 생성한 블록의 머클 루트를 받아서 저장한다.
deposit: 새로운 이용자가 플라즈마 체인에 참여하려 할 때 예치금(deposit)을 저장한다.
startExit: 플라즈마 체인에 있는 특정 UTXO(unspent transaction output)를 인출한다.
challengeExit: 정당하지 못한 인출 시도를 막는다.

오퍼레이터는 플라즈마 체인에서 블록을 생성하는 일종의 권한증명(Proof of Authority) 방식의 단일 채굴자 노드로 볼 수 있다. 기존 플라즈마 백서에서는 다수의 오퍼레이터들이 합의 알고리즘에 따라 플라즈마 블록을 생성하는 디자인을 제시하고 있으나, MVP에서는 합의 알고리즘을 도입함에 따라 발생하는 복잡성을 일단은 배제하기 위해 단일 오퍼레이터에게 블록 생성 권한을 주는 상황을 상정하고 있다. 따라서 오퍼레이터는 플라즈마 체인상에서 발생하는 트랜잭션들을 모아 블록을 생성하고, 블록의 머클 루트를 플라즈마 컨트랙트에 보내어 저장하는 역할을 맡는다.

새로운 유저가 플라즈마 체인에 참여하기 위해서는, 플라즈마 체인에서 사용할 자신의 코인을 플라즈마 컨트랙트로 전송한다. 컨트랙트에서는 이용자가 보내준 예치금을 저장하고, 해당 값만큼의 UTXO(unspent transaction output)를 생성하는 블록을 플라즈마 체인에 추가한다. 유저는 이 이후부터 자신의 UTXO를 이용하여 플라즈마 체인 내부에서 트랜잭션을 발생시키고 이를 오퍼레이터를 통해 플라즈마 블록에 기록하여 승인받게 된다.

MVP에서의 트랜잭션은 2개의 input, 2개의 output으로 이루어진 가장 단순한 구조를 갖는다. 각 블록에는 2¹⁶개의 트랜잭션이 담길 수 있고, 따라서 depth-16의 머클 트리 루트가 플라즈마 컨트랙트에 담기게 된다. 실제로 A가 B에게 UTXO를 보내는 트랜잭션을 생성하려면 다음과 같은 절차가 이루어진다.

A가 B의 주소(address)를 묻는다.
A의 UTXO들을 B의 주소로 보내는 트랜잭션을 생성하여 블록 생성자에게 보낸다.
- A의 UTXO 정보: blknum, txindex, oindex
- A의 서명: sig
- B의 주소: newowner
- 보내는 UTXO의 크기: denom
트랜잭션이 블록에서 확정되기를 기다린다.
서명된 확정(confirm) 메시지를 생성하여 B에게 발송한다.

유저가 자신의 UTXO를 메인넷으로 인출하고자 할 때는, 플라즈마 컨트랙트의 startExit 함수를 호출한다. 인출이 요청된 UTXO는 우선 컨트랙트의 priority queue에 저장되어있다가, 해당 UTXO가 14일 이상 경과하게 되면 과거에 발생한 UTXO부터 순차적으로 메인넷으로 인출해준다. 이 기간은 정당하지 못한 UTXO에 대한 인출 시도를 막기 위한 이의제기(challenge) 기간인데, 이미 사용된 TXO(spent transaction output)를 인출하려는 시도를 관찰한 다른 이용자는 플라즈마 컨트랙트의 challengeExit 함수를 호출한다. 이때, 해당 TXO가 사용된 트랜잭션에 대한 증거를 함께 제공함으로써 플라즈마 컨트랙트는 UTXO가 사용됐는지 여부를 확인할 수 있다.

MVP는 플라즈마 구현을 위한 가능한 단순한 디자인을 제시했지만, 아직 고려해야 할 문제점들이 다음과 같이 남아있다.

플라즈마 체인 상에서 오퍼레이터로 인한 문제가 발생할 경우, MVP 이용자는 플라즈마 체인을 빠져나오는 것이 유일한 방법이다. 특히 단일 오퍼레이터를 가정하고 있는 MVP에서는 오퍼레이터가 가짜 트랜잭션을 생성하여 자신에게 임의의 UTXO를 생성한 후 인출을 시도할 수 있다. 플라즈마 체인의 모든 정보를 일일이 확인할 수 없는 플라즈마 컨트랙트에서는 UTXO가 정당한지 여부를 알 수 없기 때문에, 컨트랙트에 예치된 금액을 오퍼레이터가 가져가고, 따라서 일반 이용자들이 자신의 자산을 온전히 돌려받을 수 없게 된다. 따라서 MVP 이용자들은 가짜 UTXO가 생성된다면, 플라즈마 체인에서의 모든 활동을 멈추고 자신의 UTXO를 1주일 이내에 인출을 시도해야 손해를 피할 수 있다. 뿐만 아니라 오퍼레이터가 새로 생성된 블록을 이용자에게 공유하지 않는 경우에도, 이용자의 입장에서는 플라즈마 체인을 빠져나오는 것이 안전한 방법이다.
MVP 이용자는 적어도 일주일에 한 번 이상은 플라즈마 체인 상의 모든 새로운 트랜잭션들을 검증해야 하며, 메인넷의 플라즈마 컨트랙트에 요청된 인출 요청까지도 확인하고 있어야 한다는 부담을 갖는다. 플라즈마 체인을 지속적으로 검증해야 문제가 발생하는지 여부를 확인할 수 있으며, 메인넷의 플라즈마 컨트랙트를 관찰해야 악의적인 이용자가 TXO를 인출하려는지를 확인하고 이의제기를 할 수 있다.
악의적인 이용자가 플라즈마 체인에서 이미 사용된 TXO를 인출하려고 시도하는 경우에는 다른 이용자가 이를 확인하고 이의제기를 수행해야 하는데, 이 과정에서 이용자들 간에 일종의 눈치싸움이 발생할 수 있다. MVP에서는 악의적인 이용자에 의해 TXO가 인출되면, 추후에 나머지 이용자들이 인출을 시도할 때 플라즈마 컨트랙트의 잔액이 부족해서 누군가는 자신의 자산을 인출하지 못하는 사태가 일어날 수 있다. 따라서 모든 이용자들이 플라즈마 컨트랙트에서 부정한 TXO 인출이 일어나지 못하게 감시를 하고 있어야 하고, 모두가 플라즈마 블록 정보를 가지고 있기에 이의제기를 할 정보를 가지고 있다. 그러나 반대로 살펴보면, 어느 한 이용자가 이의제기해야 할 의무를 갖지 않는 반면, 심지어 이의제기를 위해서는 자신의 자산에서 메인넷의 가스 사용료(gas fee)를 부담해야 한다. 또한 TXO 인출을 막지 않더라도, 플라즈마 컨트랙트의 잔액이 다 떨어지기 전에 이용자가 자신의 자산을 인출하면, 본인은 손해를 보지 않기 때문에 이기적인 행동을 할 수도 있다.
MVP 이용자가 플라즈마 체인을 빠져나오거나(exit), 이의제기할 때는 메인넷에서 트랜잭션을 발생시켜야 하는데, 메인넷의 트랜잭션 처리량이 충분하지 못하여 모든 트랜잭션을 처리하지 못하거나 가스(gas)값이 비정상적으로 높은 상황에서는 MVP 이용자가 손해를 입게 될 수 있다. 특히 플라즈마 체인에서 문제가 발생하거나 TXO 인출이 시도되는 경우에는, 7일이 지나기 전에 exit 혹은 이의제기 트랜잭션을 발생시켜야 하고, 이 기간 내에 성공하지 못하면 손해를 입게 된다.
임의의 A가 B에게 UTXO를 전송하는 트랜잭션을 발생시킬 때 완료될 때까지의 절차가 복잡하다. A는 트랜잭션을 생성하여 오퍼레이터가 블록에 포함시키도록 해야 하며, 블록의 머클 루트가 메인넷에 포함됐는지를 확인하고, 해당 블록까지의 모든 블록이 정당한지(validity)를 확인하여, 확정 메시지를 B에게 전달해야 트랜잭션이 완료된다.

다음으로는 위의 문제를 해결하기 위하여 오퍼레이터가 임의의 UTXO를 생성하는 것이 불가능하도록 만들고, 이용자의 플라즈마 체인 검증 부담을 획기적으로 낮춘 플라즈마 캐시(Plasma Cash)에 대해 알아보도록 하자.

플라즈마 캐시(Plasma Cash)

Ethereum Community Conference, 8th March

플라즈마 캐시는 기존의 플라즈마와 대부분의 디자인 요소가 동일하지만, 플라즈마 체인에서의 예치금의 형태와 트랜잭션 저장 형식이 바뀌었다.[7] 각각의 예치금(deposit)은 각각 자신의 고유 ID를 가지고, 쪼개지거나 합쳐질 수 없는 NFT(non-fungible token)의 형태로 플라즈마 체인에서 사용되며, 플라즈마 블록에서 트랜잭션의 머클 트리를 구성할 때 트랜잭션 순서대로 배열된 일반적인 바이너리 머클 트리(binary merkle tree) 대신에 토큰의 ID 순서대로 배열된 희소 머클 트리(sparse merkle tree)를 사용한다.

각각의 예치금이 쪼개지거나 합쳐질 수 없는 NFT를 사용하는 것은 언뜻 보면 매우 비효율적인 방식으로 보인다. A라는 이용자가 만약 5 ether에 해당하는 NFT를 가지고 플라즈마 체인에 참여하여 이 중 2 ether만을 B에게 전송하고 싶다면, 5 ether NFT를 3 ether NFT와 2 ether NFT로 나누어 줄 수 있는 제3자를 찾아서 작은 단위의 NFT로 교환하고, 이 중 2 ether NFT를 B에게 전송하는 과정을 거치게 된다. 현실 화폐에 비유하자면 기존의 MVP는 전자 뱅킹과 같이 1원 단위의 전송도 쉽게 수행할 수 있는 반면, 플라즈마 캐시에서는 10,000원짜리 지폐만 가지고 있다면 잔돈을 바꾸지 않는 한 5,000원만 다른 사람에게 전달할 방법이 없다.

반면 플라즈마 캐시는 유저의 입장에서 토큰이 아직 소비되지 않았다는 유효성(validity)을 확인하는 과정을 매우 효율적으로 만들어 준다. 플라즈마 캐시 체인에 존재하는 모든 토큰은 각각 예치되는 순간부터 인출되는 순간까지 변하지 않는 고유 ID를 가지게 된다. 따라서 토큰의 과거 트랜잭션 기록과 나머지 각각의 블록에서 사용되지 않았다는 머클 증명(proof of non-inclusion)을 확인하면 토큰이 전체 과거 이용내역을 확인할 수 있고, 이중지불(double spending)을 하지 않았다는 것 또한 확신할 수 있다. 이 증명은 t개의 플라즈마 블록이 생성되었고, n개의 토큰 ID가 있을 때, t*log(n)의 증명 크기를 갖는다. 따라서 플라즈마 체인에서 해당 토큰을 전송할 때는, 이 증명을 수신자에게 전달함으로써 수신자가 자신의 토큰의 유효성을 확인할 수 있다.

플라즈마 오퍼레이터의 입장에서도 유저와의 통신을 더 쉽게 관리할 수 있다. 매 블록이 새로 생성될 때마다 플라즈마 오퍼레이터는 각 토큰 소유자에게 각자가 소유하고 있는 토큰에 대한 사용 또는 미사용 증명(proof)을 발송하면, 토큰의 소유자들은 자신의 토큰의 안전성을 확인하고, 자신이 소유하고 있지 않은 토큰에 대한 불필요한 정보는 전혀 확인할 필요가 없다.

그러면 앞서 언급했던 MVP에서의 문제점 중 플라즈마 캐시에서는 어떤 문제점이 해결되었고 또 어떤 문제점이 남아있는지, 그리고 어떤 해결책이 모색될 수 있는지를 다시 짚어보도록 하자.

MVP에서는 오퍼레이터의 악의적인 행동이 발생할 경우 플라즈마 이용자들은 플라즈마 체인을 빠져나오는 것이 최선의 방법이었는데, 이 문제는 플라즈마 캐시에서는 상당 부분 해결이 되었다. 우선 오퍼레이터가 가짜 트랜잭션을 생성하여 인출을 시도하는 경우에는 플라즈마 캐시에서는 해당 토큰의 ID를 확인하여, 해당 ID의 토큰을 소유하고 있는 이용자가 이의제기(challenge)를 하게 된다. 해당 이용자는 증명 가능한 토큰의 과거 전체 사용 이력을 보유하고 있기 때문에, 오퍼레이터의 인출 시도는 실패하게 된다. 그러나, 오퍼레이터가 블록을 주변에 공유하지 않는 ‘block withholding’을 시도하는 경우에는 이용자들은 결국 플라즈마 체인에서 빠져나가야 한다.
플라즈마 이용자들이 플라즈마 체인과 플라즈마 컨트랙트를 지속적으로 검증하거나 관찰해야 하는 부담은 크게 줄었다. 플라즈마 캐시의 이용자들은 이제 전체 플라즈마 체인이 아닌 자신이 보유한 토큰 ID의 사용 내역만 검증하면 된다. 반면, 플라즈마 컨트랙트는 여전히 지속적으로 관찰해야 하는데, 이는 별도로 플라즈마 컨트랙트를 관찰하여 플라즈마 체인의 내용과 비교해주는 새로운 역할을 가진 노드를 도입한다면 해결할 수 있을 것으로 보인다.
TXO 인출 시도에 대해 이용자들이 적극적으로 이의제기를 시도하지 않을 수 있다는 문제점은 완전히 해결될 수 있다. 플라즈마 캐시에서는 토큰 ID에 의해 각각의 예치금의 소유주가 확실하게 정해지기 때문에, 이미 사용된 토큰을 인출하려는 경우에는 해당 토큰을 실제로 소유한 이용자가 이의제기 과정을 자율적으로 수행하게 된다.
메인넷의 상황에 따라 트랜잭션의 처리가 용이하지 못할 경우 플라즈마 이용자가 손실을 입을 수 있는 문제는 플라즈마 캐시에서도 동일하게 적용된다. 이는 플라즈마가 근본적으로 해결해 나가야 할 문제점이다.
MVP에서 트랜잭션이 완료되기 전에 승인 메시지를 생성해야 하는 절차가 플라즈마 캐시에서는 생략될 수 있다. MVP에서는 오퍼레이터가 트랜잭션을 제때 공개하지 않으면서 정당하지 못한 블록을 생성하여 A가 손해보게되는 상황을 방지하기 위하여 이용자가 최종 승인 메시지를 생성하도록 하였으나, 플라즈마 캐시에서는 이러한 공격이 더이상 불가능하기 때문에 승인 과정을 생략할 수 있다.

그러나 아직 플라즈마 캐시가 해결해야 할 문제점은 남아있다. 1) 플라즈마 캐시는 NFT를 사용함에 따라 원하는 금액을 자유롭게 전송하지 못하고, 2) 각 토큰의 과거 사용/미사용 내역을 증명하기 위한 데이터의 크기는 시간이 지남에 따라 선형적으로 커지게 된다. 추가적으로 이러한 문제를 해결하기 위해 제안된 두 가지 기술을 소개한다.

플라즈마 캐시 확장기법 — 플라즈마 데빗(Plasma Debit)

플라즈마 데빗은 플라즈마 캐시에 덧붙여 부분 잔고(partial balance) 개념을 도입함으로써, 플라즈마 캐시가 NFT에서 지정하고 있는 예치금의 크기보다 작은 단위의 금액을 거래할 수 있도록 만든 솔루션이다. 플라즈마 캐시에서는 블록에서 각 거래의 기록이 토큰 ID를 기준으로 한 sparse simple 머클 트리 형태로 저장되어있으며, 이 머클 트리에서는 해당 토큰에 저장된 고정된 deposit 값과 토큰 소유주의 주소 값을 저장한다. 이들 항목에 덧붙여, 플라즈마 데빗에서는 추가적으로 잔액 비율(deposit portion)을 머클 트리에 저장한다. 예를 들어 임의의 토큰의 초기 예치금이 10이더일 경우 처음에는 예치금 대비 잔액 비율이 1이지만, 이후 거래에서 소유주가 보유한 금액이 5이더가 되면 잔액 비율이 0.5로 표시되며, 나머지 5이더는 오퍼레이터가 소유하게 된다.

잔액 비율을 이용한 트랜잭션을 활용하면 1) 플라즈마 데빗 상에서 거래가 일어날 때마다 오퍼레이터에게 소량의 수수료를 지급하는 것이 가능하고, 2) 임의의 A에서 B로 원하는 양의 금액만을 보내는 것이 가능해진다. 단, 임의의 금액을 송금할 때에는 송신자 토큰의 잔액 비율을 낮추고, 수신자의 잔액 비율을 높이는 과정을 단일(atomic) 절차로 지원해야 한다.

플라즈마 캐시 확장기법 — 플라즈마 XT

플라즈마 캐시에서 각 토큰의 소유주는 추후 발생할 수 있는 토큰의 소유 문제를 해결하기 위해, 해당 토큰의 과거 기록을 전부 가지고 있어야 한다. 이는 t*log(n)의 크기를 갖는 증명이 될 것이고, 블록의 개수(t)가 늘어남에 따라 기록의 크기는 선형적으로 증가하게 된다. 플라즈마 XT에서는 이 문제를 해결하기 위해 타임라인의 중간 중간에 토큰의 소유주를 완결짓는 체크포인트(checkpoint)를 도입하였다. 체크포인트를 도입하게 되면, 토큰의 소유주는 가장 최초로 예치된 순간부터의 기록(history) 전체가 아닌, 마지막 체크포인트부터 현재까지의 기록만을 갖고 있으면 충분하기 때문에 보관해야 할 기록의 크기를 주기적으로 초기화함으로써 부담을 획기적으로 낮출 수 있다.

플라즈마 구현 프로젝트

플라즈마는 이더리움 재단에서 백서를 제시하고 여러 플라즈마 기법에 대한 논의를 장려하고 있으나, 실제 개발은 OMG, Loom Network 등 각각의 프로젝트팀에 의해 개별적으로 이루어지고 있다. 각 프로젝트팀에서는 자신들의 프로젝트에 필요한 이더리움 확장성 솔루션을 확보하기 위해 개발을 진행하고 그 코드를 공개하고 있으며, 비교적 많이 알려진 개발 코드는 다음과 같다.

gitHub tpmccallum, 플라즈마 구현 프로젝트 목록

맺음말

블록체인 기술의 확장성에 대한 논의가 본격적으로 진행되면서, 플라즈마 뿐만 아니라 다양한 블록체인 플랫폼에서 서로 다른 방식으로 확장성을 제시하는 프로젝트들이 등장하고 있고, 초기 형태의 실제 구현체도 속속 나오고 있다. 아직은 이들 확장성 솔루션들의 성능을 직접 체감해보기는 어렵지만, 블록체인 기반 상용화 서비스들이 많아지면서 함께 시너지를 발휘하는 모습을 곧 볼 수 있을 것이다.