Base, MegaETH와 Solana의 사전 확인 메커니즘 비교: 속도와 안전은 어떻게 균형을 이루는가?

저자：Shiva

편집: Tim, PANews

Base, MegaETH 및 Solana의 사전 확인 메커니즘은 각각 Flashblocks, Miniblocks 및 Shreds입니다.

누가 가장 빠른가?

누가 가장 안전한가?

누가 승리할 것인가?

당신이 알아야 할 모든 것입니다:

TLDR:

• Flashblocks, miniblocks 및 shreds는 각각 Base, MegaETH, Solana 체인의 "사전 확인" 메커니즘입니다.
• 사전 확인 메커니즘은 사용자에게 "포함 보장"을 제공하여 거래가 다음 블록에 포함될 것임을 보장합니다.
• 사전 확인 메커니즘은 사용자 경험을 향상시킬 수 있지만, 사용자가 블록 생성자가 정직하고 신뢰할 수 있다고 믿어야 합니다.

Base Flashblocks

Base의 현재 블록 확인 시간은 2초입니다.

2초마다 블록 탐색기, RPC, 지갑 등 모든 도구가 블록 및 데이터베이스의 상태 업데이트를 가져오고 사용자와 공유합니다.

위의 상태 업데이트는 "최종 확인성"(불변성)이 부족하지만, 정렬자는 "사전 확인"을 수행했습니다.

2초의 업데이트 지연은 사용자 경험을 잘 제공하지 않으며, 사용자는 더 높은 속도에 익숙해져 있습니다.

Flashblocks는 사전 확인 시간을 200밀리초로 줄여 이 사용자 경험 문제를 직접 해결합니다:

• 정렬자는 신뢰할 수 있는 실행 환경(TEE)에서 실행되며, 우선 비용에 따라 거래를 정렬합니다.
• 200밀리초마다 정렬자는 서브 블록(Flashblock)을 생성하고 이를 L2 노드에 방송합니다.
• L2 노드는 TEE 서명을 검증하고 사용자에게 사전 확인을 발송하며, Flashblocks를 로컬 상태에 적용합니다.
• 2초 후, 정렬자는 전체 블록을 컴파일하고 L1에 제출할 머클 요약을 생성합니다.
• L1이 최종 확인되면 L2 노드는 하드 상태를 업데이트하여 블록의 최종 확인을 완료합니다.

전체 블록의 확인은 여전히 2초가 걸리지만, 사용자는 200밀리초 내에 업데이트된 상태를 볼 수 있어 사용자 경험이 크게 개선됩니다.

MegaETH Miniblocks

MegaETH는 현재 블록 시간을 1초로 설정할 계획입니다.

그러나 그들은 사용자 경험을 개선하기 위해 Flashblocks와 유사한 사전 확인 메커니즘을 사용할 것입니다.

MegaETH 정렬자는 블록을 구축할 때(거래의 임의 순서에 따라) 거래를 출력합니다.

MegaETH는 10밀리초마다 사전 확인을 수행할 계획이며, 이를 "Miniblocks"라고 부릅니다.

Flashblocks와 유사하게, Miniblocks는 1초 블록에 대한 신뢰를 증가시키지 않으면서 사용자 경험을 크게 향상시킬 수 있습니다.

(Flashblocks를 사용할 때, 사용자는 우선 순위 정렬이 올바르게 작동하도록 TEE(신뢰할 수 있는 실행 환경)를 추가로 신뢰해야 한다는 점에 유의해야 합니다.)

Solana Shreds

Solana는 우수한 사용자 경험과 고속 거래를 제공하는 블록체인 선구자입니다.

Solana의 정상 블록 시간은 400밀리초입니다.

그러나 블록 생성 과정에서 Solana의 블록 생성자는 블록을 더 작은 부분으로 나누어 "Shreds"라고 부르며, 이를 역사적 증명(PoH)에 제출한 후 이러한 Shreds를 네트워크의 다른 부분으로 전파합니다.

다른 검증자가 Shreds를 받으면 거래를 복제하기 시작하고 Shreds를 검증한 후 즉시 거래를 전송할 수 있습니다(400밀리초 미만).

이제 두 가지 문제가 발생했습니다:

1. 각 경우에서 이러한 "사전 확인"은 얼마나 안전한가?
2. 거래가 일괄 처리되어 L1에 전송될 때 최종 확인되는 경우, 롤업에 대해 "블록 시간"은 무엇을 의미하는가?

사전 확인의 안전성

a) Solana

Solana 검증자가 블록 생성자로부터 2개의 Shreds를 받았다고 가정하지만, 이러한 Shreds는 최종 블록의 일부가 되지 않았습니다. 이는 다음 두 가지 이유로 발생할 수 있습니다:

1. 블록 생성자가 오프라인: 최종 블록을 생성하지 않았고 해당 슬롯이 건너뛰어졌습니다. 이 경우 다음 블록 생성자가 이러한 Shreds를 인수하고 자신의 블록에 포함시킵니다(최장 분기에서 복제).
2. 블록 생성자의 악의적 행동: 블록 생성자가 서로 다른 검증자에게 서로 다른 Shreds를 전파하여 네트워크를 분열시키려는 의도입니다.

따라서 포함 보장은 간단히 말해: 블록 생성자가 악의적이지 않거나 부패하지 않다고 믿는 것입니다.

b) MegaETH

정렬자는 하나만 존재합니다. 따라서 포함 보장은 해당 정렬자가 악의적이지 않다고 믿는 것입니다.

다른 두 가지 위험은:

i) 정렬자가 오프라인: 이 경우, 정렬자가 다시 온라인 상태가 되면 사전 확인된 거래를 포함할 것입니다.

ii) 이더리움 L1에서 재구성이 발생: 최종 확인되지 않은 모든 L2 거래는 정렬자가 새로운 분기에서 복제합니다.

c) Base

MegaETH와 유사한 포함 보장입니다.

여기서 포함 보장은 정렬자가 악의적이지 않다고 믿고 TEE(신뢰할 수 있는 실행 환경)가 안전하다고 믿는 것입니다.

그러나 TEE가 해킹당하더라도 유일하게 변경될 수 있는 것은 거래의 우선 순위 순서입니다.

모든 경우에 사용자는 더 빠른 사전 확인을 받을 수 있지만, 위험은 블록 생성자가 부패할 수 있다는 것입니다.

단일 블록의 블록 생성자가 주어진 시간에 블록 구축에 대한 독점권을 가지므로, 부패 행동이 매번 블록 구축에서 동일한 확률을 가진다고 가정하는 것이 합리적입니다.

L2의 블록 시간은 무엇을 의미하는가?

L1 블록체인은 합의 메커니즘을 가지고 있으며, 대부분의 L2 블록체인은 그렇지 않습니다.

L1 공공 블록체인에서 고정된 블록 시간은 합의 효율성을 높일 수 있습니다. 검증자의 투표 행동이 블록 생성의 중요한 시간 노드에 집중되기 때문입니다. 검증자는 투표를 통해 전체 블록 내 모든 거래의 정확성을 확인합니다.

L2의 블록 시간은 의미가 있는가?

답은 확실히 그렇습니다.

L2의 블록 시간은 자유롭게 설정할 수 있으며 "사전 확인"을 나타내고 최종 확정성을 나타내지 않지만, 고정 블록 시간은 여전히 다음과 같은 주요 가치를 가지고 있습니다:

• EIP1559와 같은 수수료 메커니즘을 구현할 때, 블록 수준에서 작업을 수행하면 빈번한 서브 블록/플래시 블록 수준(miniblock/flashblock)보다 실행 효율성이 크게 향상됩니다.
• L2가 분산된 정렬 및 검증 프로세스를 구현할 계획이라면, 명확한 블록 경계를 설정하는 것이 효율성을 크게 높일 수 있습니다. 왜냐하면 투표 및 검증 행동이 특정 시간 창 내에서 집중적으로 수행될 수 있기 때문입니다.

블록체인 성능이 향상됨에 따라 더 빠른 아초 단위의 사전 확인이 일반화될 것입니다.

최종적으로 승리하는 메인 체인은 부패 행동이 발생할 확률이 효과적으로 억제되도록 보장할 것입니다.