비탈릭 부테린의 이더리움 개발자 컨퍼런스 연설 정식 버전

편집자 주: 이 기사의 출처는배빗, 저자: Helen, 허가를 받아 출판됨.

편집자 주: 이 기사의 출처는

배빗

, 저자: Helen, 허가를 받아 출판됨.

2019년 6월 29일, CSDN과 Lingtai Technology가 공동으로 후원하는 "2019 Ethereum 기술 및 애플리케이션 컨퍼런스"가 베이징에서 개최되었습니다.

중국에서 가장 영향력 있는 이더리움 기술 컨퍼런스인 이 컨퍼런스는 이더리움의 생태적 파노라마, 이더리움의 미래 발전, 이더리움의 실제 발전, 고품질 프로젝트 사례 등에 초점을 맞추고, 이더리움 창시자인 Vitalik Buterin, 핵심 기술 개발자 Hsiao-Wei Wang, 국내외 유명 프로젝트 리더, 업계 리더, 이더리움 생태 엘리트 전문가가 이더리움 생태계의 새로운 발전에 대해 논의하고 최신 이더리움 개발 경험을 공유했습니다.

이더리움 창시자 비탈릭 부테린(Vitalik Buterin)은 이번 컨퍼런스에서 뜨거운 박수 속에 "이더리움 2.0 교차 샤드 거래"를 주제로 첫 연설을 했다. 비탈릭은 개발자들에게 이더리움 2.0의 개념과 진행 상황을 자세하게 소개하고, 개발자들이 고민하는 "이더리움 성능"이라는 주제를 겨냥해 크로스 샤드 트랜잭션의 원리를 개발자들에게 소개하고, 개발자들의 공통된 질문에 답을 얻었다. 답변.

현재 체인에서 모든 노드는 모든 트랜잭션을 다운로드하고 확인하며 이는 안전하지만 확장성을 심각하게 제한합니다. 그래서 우리는 이 상황을 개선하고자 합니다.미래에는 블록체인이 조각화되어 각 노드가 트랜잭션의 일부만 다운로드하고 확인합니다.

예를 들어, 이더리움 2.0의 설계에는 1024개의 샤드가 있으므로 각 노드는 1/1024개의 트랜잭션만 확인하면 됩니다. .초당 10,000건의 거래가 가능하지만 다음과 같은 새로운 문제에 직면하게 됩니다.

사용자와 애플리케이션은 서로 다른 샤드에 있습니다. 어떻게 "통신"합니까?

이제 모든 계정, 스마트 계약은 하나의 컴퓨터(이더리움을 의미함)에 저장되며 서로 통신하는 것이 매우 편리합니다. 하지만 앞으로 우리의 계정과 계약이 서로 다른 샤드에 있다면 즉각적인 대화와 소통이 어려울 것입니다.

따라서 이더리움 2.0의 설계는 각 노드가 모든 트랜잭션과 정보를 처리하도록 허용하지 않습니다. 우리는 1024개의 샤드를 가지고 있으며 각 샤드는 짧은 체인에 해당합니다. 각 샤드는 자체 합의 알고리즘을 가지고 있습니다. . 하나의 샤드에서 트랜잭션이 발행된 후 6분마다 각 샤드가 "통신"합니다. 즉, 다른 샤드의 해시 값이 발견됩니다. 비콘 체인은 합의 알고리즘과 교차 샤드 통신을 관리합니다.

"비동기" 트랜잭션 이것이 이전에 설계한 것입니다. 예를 들어, 저는 5개의 코인을 가지고 있고 Bob에게 이체하고 싶습니다. Bob은 계정이 있고 그의 계정은 맨 아래에 있고 내 계정은 맨 위에 있습니다. 우선 상단에서 트랜잭션 요청을 하고 싶은데 이 트랜잭션은 첫 번째 샤드에서 처리한 후 해쉬값을 생성하지만 바로 완료되지는 않고 다음에 샤드에 넣을 수 있습니다. 하단 샤드에서 검증이 되면 트랜잭션 처리가 가능합니다.

예를 들어 기차표와 호텔을 예약하고 싶다면 당연히 함께 예약하고 싶은데 하나만 있으면 말이 안되고 기차와 호텔이 다른 샤드에 있다면? ?

우리는 두 개의 스마트 계약을 상상합니다. 하나는 기차표를 예약하는 데 사용되고 다른 하나는 호텔을 예약하는 데 사용됩니다. 이 중 하나라도 실패하면 트랜잭션을 되돌릴 수 있습니다. 하지만 두 계약이 서로 다른 샤드에 있기 때문에 일관성을 보장하기가 더 어렵습니다.

솔루션 중 하나는 "양크"입니다. 각 기차표에는 계약이 있고 각 객실에는 계약이 있으므로 각 계약은 좌석을 예약하거나 객실을 예약하는 능력을 나타낼 수 있습니다. 지금 무엇을 할 수 있습니까? 한 번에 하나의 계약을 사용하는 기능을 가진 "양크"에서 계약을 시작합니다. 호텔 샤드에서 컨트랙트를 가져오고, 기차표에서 또 다른 컨트랙트를 가져와 동시에 두 개의 샤드를 예약합니다. 그리고 귀하가 예약을 포기했는데 다른 사람들이 여전히 예약을 원하면 귀하는 그들의 계약을 "끌어당겨" 넣을 수 있습니다. 둘 다 주문하거나 둘 다 주문하지 않는 자동 프로세스입니다.

그러나 한 샤드가 다른 샤드의 데이터 또는 해시 값을 알도록 하는 데 5분을 소비해야 하지만 이 애플리케이션이 더 빨라지기를 원한다고 상상해 보십시오.

예를 들어, 초기에 Alice는 10개, Bob은 20개, Charlie는 52개를 가지고 있습니다. 우리는 이것을 압축하여 저장합니다. 두 가지 상황이 있습니다. 하나는 bob이 20개의 코인을 가지고 있고 다른 하나는 Bob이 이후에 25개의 코인을 가지고 있는 것입니다. 위의 루트가 R인 지갑을 보면 다음 샤드에서 추측할 수 있습니다. 즉, Bob은 25개의 코인을 가지고 있으므로 다른 사람에게 25개의 코인을 가져갈 수 있습니다.

그러나이 과정에서 트랜잭션이 완료된 것으로 보이지만 계산이 완료되지 않았습니다. 그러면 Bob이 이 동전을 가지고 있는 것 같지만 이 동전을 사용하지 않았다고 물을 수 있습니다. 밥이 찰리에게 25코인을 보내고 싶다고 가정해 봅시다. 밥은 어떻게 할까요?

우리는 R이 진짜인지 가짜인지 생각할 필요가 없습니다. Charlie는 이제 52개의 동전을 가지고 있기 때문에 R이 진짜임에 틀림없다는 것을 알고 있기 때문입니다. 이러한 논리는 백그라운드에서 이루어지며 논리적인 효과는 밥과 찰리의 지갑 분석을 통해 최소한 그런 거래가 발생했다는 것은 알고 있습니다. 통신을 사용하여 블록체인에서 트랜잭션을 수행할 수 있고 다른 블록체인에서 크로스체인 트랜잭션을 수행할 수 있는 애플리케이션을 만들 수 있다는 것은 매우 흥미로운 일입니다.

우리는 또한 플라즈마 방법을 통한 동기 트랜잭션과 같은 다른 목표를 달성할 수 있습니다. 트랜잭션은 모든 샤드에서 시작할 수 있으며 자산은 계약에 저장되지만 총 상태 수를 즉시 계산하지 않고 시간이 걸립니다. 철회하는 주. 이때 상태가 유효하지 않음을 증명할 수 있는 사람은 누구든지 출금을 취소할 수 있습니다.

이 방법은 우리가 코인을 받고 불법 지불을 하지 않는 경우 거래가 방송을 위해 전체 블록체인에 동기화되도록 할 수 있습니다. 우리에게는 X와 Y라는 두 개의 자산이 있고 샤드에는 고유한 우선 순위가 있습니다. 이는 다음 트랜잭션 이전의 트랜잭션일 수 있습니다.

우리가 거래 프로세스에 참여하고 자산이 있고 거래 정보를 보내고 싶다면 모든 샤드에 게시할 수 있습니다. 자산의 소유자인 경우 이러한 샤드를 분석하고 이러한 트랜잭션의 기록이 무엇인지 평가할 수 있습니다.

우리가 "활성 가상 머신(OVM)"이라고 부르는 이러한 디자인은 귀하가 소유한 자산이 즉시 이전되지 않고 프로세스를 시작하며 돈을 인출할 필요가 없으며 실제로 도착하는 데 일주일이 걸릴 수 있지만 귀하가 사용자라면 특정 자산을 즉시 인출할 수 없는 이유를 알 수 있으며 이 거래가 실제로 입금될 수 있다는 느낌이 듭니다.

이것의 장점은 우리가 거래를 개시할 수 있는 능력을 얻게 될 것이고, 적시에 확인될 수 있다는 것인데, 이는 0.5초 안에 즉시 확인될 수 있습니다. 그렇다면 사용자 경험은 중앙 집중식 서버에서 제공하는 경험과 유사하게 매우 좋을 것입니다.

서로 다른 샤드에서 데이터를 게시하면 논리가 매우 복잡해지고 스마트 계약도 매우 복잡해지며 사용자 지갑은 많은 계산을 수행하므로 계산하는 데 시간이 더 오래 걸립니다.