"샤드"의 두 판 사이의 차이

해시넷
이동: 둘러보기, 검색
(참고자료)
(특징)
1번째 줄: 1번째 줄:
 
샤드란 샤딩을 통해 나누어진 블록들의 구간 (혹은 Epoch)을 ‘샤드’라고 부른다. 샤드는 지분 증명과 관련이있는 것이 아니라 확장 성 개선과 관련된 개념이다. '샤딩'의 아이디어는 가능한 계정 (계약도 계정)의 공간을 숫자 주소의 첫 번째 숫자를 기준으로 하위 공간으로 분할하는 것이다. 샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
 
샤드란 샤딩을 통해 나누어진 블록들의 구간 (혹은 Epoch)을 ‘샤드’라고 부른다. 샤드는 지분 증명과 관련이있는 것이 아니라 확장 성 개선과 관련된 개념이다. '샤딩'의 아이디어는 가능한 계정 (계약도 계정)의 공간을 숫자 주소의 첫 번째 숫자를 기준으로 하위 공간으로 분할하는 것이다. 샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
 
==특징==
 
==특징==
*각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 요소 임) 이러한 유효성 검사기는 일반적으로 모든 샤드의 유효성을 검사 할 필요는 없습니다.
+
*각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 요소 임) 이러한 유효성 검사기는 일반적으로 모든 샤드의 유효성을 검사 할 필요는 없다.
*동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동합니다.
+
*동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동한다.
*여러 샤드를 통해 통신하고자하는 계약은 거래 수령 개념에 따라 특별한 기술을 사용해야 합니다. 계약을 직접 호출하고 영수증을 확인하는 것의 중요한 차이점은 직접 전화를하려면 호출하는 계약 코드를 실행해야하지만 영수증을 확인하려면 다른 방법으로는 영수증을 만들 수 없다는 것만 확인하면 됩니다.  
+
*여러 샤드를 통해 통신하고자하는 계약은 거래 수령 개념에 따라 특별한 기술을 사용해야 한다. 계약을 직접 호출하고 영수증을 확인하는 것의 중요한 차이점은 직접 전화를하려면 호출하는 계약 코드를 실행해야하지만 영수증을 확인하려면 다른 방법으로는 영수증을 만들 수 없다는 것만 확인하면 된다.  
 
*샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 않아도되기 때문에 Ethereum을 확장 할 수 있다.
 
*샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 않아도되기 때문에 Ethereum을 확장 할 수 있다.
 
*샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
 
*샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
 +
===수평 분할과 비교 한 샤드===
 +
수평 파티셔닝 은 일반적으로 스키마 및 데이터베이스 서버 의 단일 인스턴스 내에서 하나 이상의 테이블을 행별로 분할 한다. 인덱스를 먼저 검색 할 필요없이 특정 행을 찾을 파티션을 식별 할 수있는 명확하고 강력하며 암시적인 방법이있는 경우 인덱스 크기를 줄임으로써 (따라서 검색 노력) 이점을 제공 할 수 있다. ' '및 ' '테이블의 예. 우편 번호는 이미 찾을 위치를 나타낸다.
 +
샤딩 (Shading)은 문제를 뛰어 넘는다. 문제가있는 테이블을 같은 방식으로 분할하지만 잠재적으로 여러 스키마 인스턴스에서이를 수행한다. 큰 분할 된 테이블에 대한 검색로드를 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버 (논리적 또는 물리적)로 나눌 수 있다는 것이 명백한 이점이다. 여러 개의 격리 된 인스턴스에서 샤드를 분할하려면 단순한 수평 분할 이상이 필요하다. 데이터베이스를 쿼리 할 때 단순한 차원 테이블 만 검색하기 위해 두 인스턴스를 모두 쿼리해야하는 경우 효율성의 기대치가 사라 진다. 분할 외에도 샤딩은 서버에서 분할 가능한 큰 테이블을 분할하는 반면 작은 테이블은 완전한 단위로 복제된다.이것이 또한 샤딩이 공유 비 아키텍처 와 관련이있는 이유이다. 일단 샤드되면 각 샤드는 완전히 별도의 논리적 스키마 인스턴스 / 물리적 데이터베이스 서버 / 데이터 센터 / 대륙에 살 수 있다 . 샤드 사이에서 다른 샤드의 다른 파티션되지 않은 테이블에 대한 공유 액세스를 계속 유지할 필요가 없다.
 +
따라서 여러 서버에서 쉽게 복제 할 수 있다. (간단한 수평 분할은 불가능). 또한 데이터 센터 간의 통신 링크가 병목 현상이 발생하는 전 세계 응용 프로그램 배포에 유용하다.
 +
또한 분할되지 않은 테이블이 응용 프로그램의 요구에 따라 밀접하게 동기화되도록 스키마 인스턴스간에 일부 알림 및 복제 메커니즘이 필요하다. 이는 샤드 시스템 아키텍처에서 복잡한 선택이다. 접근 방식은 효과적으로 읽기 전용 (업데이트는 드물고 배치됨), 동적으로 복제 된 테이블 (샤딩의 일부 분배 이점을 줄임) 및 다양한 옵션에 이르기까지 다양하다.
 +
===데이터베이스 아키텍처===
 +
수평 파티셔닝은 데이터베이스 테이블의 행 이 열로 분할되지 않고 개별적으로 유지 되는 데이터베이스 설계 원칙이다. ( 정규화 및 수직 파티셔닝이 수행하는 범위가 다르다). 각 파티션은 샤드의 일부를 형성하며 ,이 파티션 은 별도의 데이터베이스 서버 또는 물리적 위치에있을 수 있다.
 +
수평 분할 방식에는 여러 가지 장점이 있다. 테이블이 여러 서버로 분할되어 분산되므로 각 데이터베이스의 각 테이블에있는 총 행 수가 줄어 듭니다. 이렇게하면 인덱스 크기가 줄어들어 일반적으로 검색 성능이 향상된다. 데이터베이스 샤드는 별도의 하드웨어에 배치 할 수 있으며 여러 샤드는 여러 시스템에 배치 할 수 있다. 이를 통해 많은 수의 컴퓨터에 데이터베이스를 배포 할 수 있으므로 성능이 크게 향상된다. 또한 데이터베이스 샤드가 데이터의 실제 세그먼테이션 (예 : 유럽 고객 대 미국 고객)을 기반으로하는 경우 적절한 샤드 멤버십을 쉽고 자동으로 추론하고 관련 샤드 만 쿼리 할 수 ​​있다.
 +
 
==활용==
 
==활용==
 
*[[Devvio]]의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 처리 할 수 ​​있다고 주장한다. 예를 들어, 각 샤드는 최대 3,000 개의 트랜잭션을 처리 할 수있는 Devv 분산 원장의 독립적인 블록체인 노드이다. Devvio CEO Tom Anderson에 따르면 다른 노드를 추가하면 처리 할 수있는 트랜잭션 수가 두 배가된다.
 
*[[Devvio]]의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 처리 할 수 ​​있다고 주장한다. 예를 들어, 각 샤드는 최대 3,000 개의 트랜잭션을 처리 할 수있는 Devv 분산 원장의 독립적인 블록체인 노드이다. Devvio CEO Tom Anderson에 따르면 다른 노드를 추가하면 처리 할 수있는 트랜잭션 수가 두 배가된다.

2019년 8월 12일 (월) 15:43 판

샤드란 샤딩을 통해 나누어진 블록들의 구간 (혹은 Epoch)을 ‘샤드’라고 부른다. 샤드는 지분 증명과 관련이있는 것이 아니라 확장 성 개선과 관련된 개념이다. '샤딩'의 아이디어는 가능한 계정 (계약도 계정)의 공간을 숫자 주소의 첫 번째 숫자를 기준으로 하위 공간으로 분할하는 것이다. 샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.

특징

  • 각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 요소 임) 이러한 유효성 검사기는 일반적으로 모든 샤드의 유효성을 검사 할 필요는 없다.
  • 동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동한다.
  • 여러 샤드를 통해 통신하고자하는 계약은 거래 수령 개념에 따라 특별한 기술을 사용해야 한다. 계약을 직접 호출하고 영수증을 확인하는 것의 중요한 차이점은 직접 전화를하려면 호출하는 계약 코드를 실행해야하지만 영수증을 확인하려면 다른 방법으로는 영수증을 만들 수 없다는 것만 확인하면 된다.
  • 샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 않아도되기 때문에 Ethereum을 확장 할 수 있다.
  • 샤드에 포함 된 정보는 여전히 다른 노드와 공유 할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.

수평 분할과 비교 한 샤드

수평 파티셔닝 은 일반적으로 스키마 및 데이터베이스 서버 의 단일 인스턴스 내에서 하나 이상의 테이블을 행별로 분할 한다. 인덱스를 먼저 검색 할 필요없이 특정 행을 찾을 파티션을 식별 할 수있는 명확하고 강력하며 암시적인 방법이있는 경우 인덱스 크기를 줄임으로써 (따라서 검색 노력) 이점을 제공 할 수 있다. ' '및 ' '테이블의 예. 우편 번호는 이미 찾을 위치를 나타낸다. 샤딩 (Shading)은 문제를 뛰어 넘는다. 문제가있는 테이블을 같은 방식으로 분할하지만 잠재적으로 여러 스키마 인스턴스에서이를 수행한다. 큰 분할 된 테이블에 대한 검색로드를 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버 (논리적 또는 물리적)로 나눌 수 있다는 것이 명백한 이점이다. 여러 개의 격리 된 인스턴스에서 샤드를 분할하려면 단순한 수평 분할 이상이 필요하다. 데이터베이스를 쿼리 할 때 단순한 차원 테이블 만 검색하기 위해 두 인스턴스를 모두 쿼리해야하는 경우 효율성의 기대치가 사라 진다. 분할 외에도 샤딩은 서버에서 분할 가능한 큰 테이블을 분할하는 반면 작은 테이블은 완전한 단위로 복제된다.이것이 또한 샤딩이 공유 비 아키텍처 와 관련이있는 이유이다. 일단 샤드되면 각 샤드는 완전히 별도의 논리적 스키마 인스턴스 / 물리적 데이터베이스 서버 / 데이터 센터 / 대륙에 살 수 있다 . 샤드 사이에서 다른 샤드의 다른 파티션되지 않은 테이블에 대한 공유 액세스를 계속 유지할 필요가 없다. 따라서 여러 서버에서 쉽게 복제 할 수 있다. (간단한 수평 분할은 불가능). 또한 데이터 센터 간의 통신 링크가 병목 현상이 발생하는 전 세계 응용 프로그램 배포에 유용하다. 또한 분할되지 않은 테이블이 응용 프로그램의 요구에 따라 밀접하게 동기화되도록 스키마 인스턴스간에 일부 알림 및 복제 메커니즘이 필요하다. 이는 샤드 시스템 아키텍처에서 복잡한 선택이다. 접근 방식은 효과적으로 읽기 전용 (업데이트는 드물고 배치됨), 동적으로 복제 된 테이블 (샤딩의 일부 분배 이점을 줄임) 및 다양한 옵션에 이르기까지 다양하다.

데이터베이스 아키텍처

수평 파티셔닝은 데이터베이스 테이블의 행 이 열로 분할되지 않고 개별적으로 유지 되는 데이터베이스 설계 원칙이다. ( 정규화 및 수직 파티셔닝이 수행하는 범위가 다르다). 각 파티션은 샤드의 일부를 형성하며 ,이 파티션 은 별도의 데이터베이스 서버 또는 물리적 위치에있을 수 있다. 수평 분할 방식에는 여러 가지 장점이 있다. 테이블이 여러 서버로 분할되어 분산되므로 각 데이터베이스의 각 테이블에있는 총 행 수가 줄어 듭니다. 이렇게하면 인덱스 크기가 줄어들어 일반적으로 검색 성능이 향상된다. 데이터베이스 샤드는 별도의 하드웨어에 배치 할 수 있으며 여러 샤드는 여러 시스템에 배치 할 수 있다. 이를 통해 많은 수의 컴퓨터에 데이터베이스를 배포 할 수 있으므로 성능이 크게 향상된다. 또한 데이터베이스 샤드가 데이터의 실제 세그먼테이션 (예 : 유럽 고객 대 미국 고객)을 기반으로하는 경우 적절한 샤드 멤버십을 쉽고 자동으로 추론하고 관련 샤드 만 쿼리 할 수 ​​있다.

활용

  • Devvio의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 처리 할 수 ​​있다고 주장한다. 예를 들어, 각 샤드는 최대 3,000 개의 트랜잭션을 처리 할 수있는 Devv 분산 원장의 독립적인 블록체인 노드이다. Devvio CEO Tom Anderson에 따르면 다른 노드를 추가하면 처리 할 수있는 트랜잭션 수가 두 배가된다.

각 샤드 (암호 지갑이기도 함)는 더 큰 네트워크에서 입력이되고 Devvio는 T1 네트워크를 호출한다. 개별 샤드는 T2라는 별도의 트랜잭션 네트워크를 통해 다른 사람과 통신 할 수 있다.

  • 유효성 검사기 파티셔닝 및 비콘 체인

첫 번째 과제는 각 샤드에 자체 유효성 검사기가 있으면 각 샤드가 전체 체인보다 10 배 덜 안전하다는 것입니다. 따라서 X 검증자가있는 비샤드체인이 샤드체인으로 하드 포크를하고 10 개의 샤드로 X 검증자를 분할하면 각 샤드에는 X / 10 검증 기가 있고 하나의 샤드가 손상되면 5.1 % 만 손상하면 된다 (51 %) / 10) 총 유효성 검사기 수 두 번째 요점은 다음과 같다. "누가 각 샤드에 대해 유효성 검사기를 선택할까? "이다. 유효성 검사기의 5.1 %를 제어하는 ​​것은 유효성 검사기의 5.1 %가 모두 동일한 샤드에있는 경우에만 피해를 준다. 검증자가 검증 할 샤드를 선택할 수없는 경우, 검증 자의 5.1 %를 제어하는 ​​참가자는 모든 검증자를 동일한 샤드에 넣을 가능성이 거의 없으므로 시스템을 손상시킬 수있는 능력이 크게 줄어 든다.

  • 크로스 샤드 거래

모델로서의 Beanstalk는 샤딩에 매우 유용한 접근 방식이 아니다. 개별 샤드가 서로 통신 할 수없는 경우 여러 개의 독립적 인 블록체인보다 낫지 않기 때문이다. 오늘날에도 샤딩을 사용할 수없는 경우 다양한 블록체인간에 상호 운용성이 요구된다. 각 참가자가 정확히 하나의 샤드를 차지하는 간단한 결제 거래 만 고려해 보자. 동일한 샤드 내에서 한 계정에서 다른 계정으로 돈을 이체하려는 경우 해당 샤드의 유효성 검증자가 트랜잭션을 완전히 처리 할 수 ​​있다. 그러나 샤드 # 1에있는 Alice가 샤드 # 2에있는 Bob에게 돈을 보내려면 샤드 # 1의 유효성 검사자 (Bob의 계정을 신용 할 수 없음) 나 샤드 # 2의 유효성 검사기 ( Alice의 계정에서 인출 할 수 없음) 전체 거래를 처리 할 수 ​​있다. 크로스 샤드 트랜잭션에 대한 두 가지 접근 방식이 있다. 동기식 : 크로스 샤드 트랜잭션을 실행해야 할 때마다 트랜잭션과 관련된 상태 전이가 포함 된 여러 샤드의 블록이 동시에 생성되며 여러 샤드의 유효성 검사기가 이러한 트랜잭션을 실행하기 위해 협업한다. 나에게 알려진 가장 상세한 제안은 여기 에 설명 된 병합블록 이다. 비동기: 여러 샤드에 영향을 미치는 크로스 샤드 트랜잭션은 해당 샤드에서 비동기 적으로 실행된다.“신용”샤드는“직불”샤드가 그 부분을 실행했다는 충분한 증거가 있으면 절반을 실행한다. 이 접근 방식은 단순성과 조정 용이성으로 인해 더 널리 사용되는 경향이 있다. 이 시스템은 오늘 코스모스, 이더 리움 세레니티, 니어, 카데나 등에서 제안된다. 이 접근법의 문제점은 블록이 독립적으로 생성되는 경우 여러 블록 중 하나가 분리 될 가능성이 0이 아니므로 트랜잭션이 부분적으로 만 적용된다는 것이다. 포크와 마주 친 두 개의 샤드와 그에 따라 블록 A와 X '에 기록 된 크로스 샤드 트랜잭션을 나타내는 아래 그림을 고려하십시오. 체인 AB와 V'-X'-Y'-Z '가 해당 샤드에서 정식 인 경우, 거래가 완료되었다. A'-B'-C'-D '및 VX가 정식이되면 트랜잭션이 완전히 포기되므로 허용된다. 그러나 예를 들어 AB와 VX가 정식이되면 트랜잭션의 한 부분이 완료되고 한 부분이 중단되어 원 자성 오류가 발생한다. 우리는 샤드 프로토콜에 제안 된 포크 선택 규칙과 합의 알고리즘에 대한 변경 사항을 다룰 때 두 번째 부분에서 제안 된 프로토콜에서이 문제가 어떻게 해결되는지 다룰 것이다. [1]

전망

오늘날 얼마나 많은 샤드를 사용할 수 있는지에 대한 정확한 측정을 제공하기는 어렵지만, 예측 가능한 미래에 블록 체인 사용자의 처리량 요구가 2 차 샤딩의 한계를 넘어 설 가능성은 거의 없다. 이러한 양의 샤드를 안전하게 운영하는 데 필요한 수많은 노드는 오늘날 결합 된 모든 블록 체인을 운영하는 노드의 수보다 훨씬 높다. 그러나 미래의 증거 프로토콜을 구축하려는 경우 오늘날이 문제에 대한 솔루션을 연구하는 것이 좋다. 현재 가장 발전된 제안은 지수 샤딩으로, 샤드 자체가 나무를 형성하고 있으며 각 상위 샤드는 일련의 하위 샤드를 조율하는 반면 자체는 다른 샤드의 하위가 될 수 있다.

각주

  1. 알렉산더 스키 다 노프 , 〈블록 체인 샤딩에 대한 권위있는 가이드, 1 부〉, 《미디움》, 2018-12-06

참고자료