프릭션리스 캐피탈 공동창립자: 엔지니어링 관점에서 왜 여전히 솔라나를 주목하는가?
작성: Logan | X
번역: TechFlow
이것은 오랫동안 트위터에서 봐온 최악의 상황 중 하나이며, 근본적으로 이 분야의 트레이더와 엔지니어 사이에 이해 부족이 있음을 드러냅니다. 자세히 살펴보겠습니다.
블록체인의 수수료는 두 가지 요소에 의해 결정됩니다—블록 공간과 상태 경쟁:
블록 공간:
-
현재 이더리움의 블록 크기는 0.08MB이며, 4844는 각 블록에 0.375MB만 추가합니다. 댕크샤딩(Danksharding)을 통해 이더리움이 목표로 하는 최종 상태에서는 초당 처리량이 1.3MB/s입니다.
-
반면 솔라나(Solana)와 같은 고처리량 블록체인은 이미 초당 100MB를 지원할 수 있는 능력을 갖추고 있어 이더리움보다 100배 높습니다.
-
엔지니어와 그들이 구축할 수 있는 애플리케이션 관점에서 이러한 차이가 얼마나 큰지를 반드시 강조해야 합니다. 주문장(Order book)은 단지 표면적인 예일 뿐입니다.
상태 경쟁:
-
상태 경쟁은 두 명 이상의 참여자가 동시에 동일한 상태에 접근하려 할 때 발생합니다. MEV 거래에 접근할 수 있는 사람은 한 명뿐입니다.
-
단일 스레드 EVM은 상태별로 수수료를 구분할 수 없기 때문에 이 문제를 해결할 수 없습니다.
-
대신 단일 스레드 EVM은 글로벌 수수료 시장을 운영하여, 특정 앱이 다른 앱보다 더 많은 리소스를 사용하면 네트워크 내 모든 앱이 수수료를 올려야 하도록 강제합니다. 이러한 설계 선택은 성능과 수수료 측면 모두에서 명백하게 열등합니다.
-
솔라나 등 차세대 블록체인은 로컬 수수료 시장을 구축함으로써 이 문제를 해결했습니다. 이는 실질적으로 여러 L2 인스턴스를 배포하면서도 유동성과 애플리케이션의 통합성을 유지하는 것과 같습니다. 반면 이더리움 생태계는 조각화된 방식을 선택했습니다.
프론트런(Front-running):
-
프론트런 문제에 대해 솔라나는 모든 사용자에게 평등하고 공정한 접근을 제공하도록 설계되었습니다.
-
최근 제가 Toly와 진행한 팟캐스트에서 우리는 솔라나의 '모든 노드 간 전파' 합의 설계에 대해 자세히 다뤘으며, 이 설계는 정보가 가능한 한 빨리 네트워크의 모든 참여자에게 전달되도록 합니다.
-
'모든 노드 간' 합의는 메시지 오버헤드가 큽니다. 그 복잡성은 N^2이지만, 솔라나는 이러한 설계를 선택했는데, 이유는 어떤 트레이더라도 노드를 연결해 네트워크 내 다른 모든 사람과 동일하고 평등한 정보를 받기를 원했기 때문입니다.
탈중앙화:
탈중앙화의 척도는 두 가지입니다: 전체 노드 수와 나카모토 계수.
-
이더리움에는 약 3,700개의 풀 노드가 있으며, 현재 922개 노드가 네트워크에 동기화되고 있습니다.
-
전체 노드는 중요합니다. 만약 불행히도 제3차 세계대전이 일어난다면, 네트워크를 복구하고 재시작하기 위해 장부의 사본이 필요하기 때문입니다.
-
솔라나는 약 2,118개의 풀 노드와 843개의 RPC 노드를 보유하고 있습니다. 두 유형 모두 장부 상태를 복구할 수 있으며, 이는 이더리움 네트워크 커버리지의 약 80% 수준입니다.
-
실시간 검열 저항성을 나타내는 나카모토 계수는 이더리움에서 약 25이고, 솔라나는 약 31입니다.
솔라나에서 개발하기:
-
솔라나 및 기타 고처리량 플랫폼의 개발자들은 본질적으로 이더리움 세계에서는 절대 불가능한 새로운 원시 기능(primitives)을 해제할 수 있기 때문에 이러한 생태계에서 개발을 선택합니다.
-
400ms의 블록 시간과 낮은 지연 시간.
-
수수료는 $0.0001에서 $0.0003 사이입니다.
통합된 고처리량 기술 스택:
-
모듈화 대 통합 논쟁을 깊이 파고들면 규모 확대가 필요한 상황이 명확해집니다. 두 설계 모두 어느 정도 형태로든 병렬 처리와 고처리량이 필요합니다.
-
유일한 논쟁은 이런 기능들이 어디서 이루어져야 하는가입니다. 여러분은 여러 L2를 통해 병렬화를 수행할 것인지, 아니면 솔라나처럼 단일 통합된 유동성과 애플리케이션 안에서 이를 통합할 것인지입니다.
-
병렬화와 처리량을 기술 스택의 다른 부분으로 이동시킬 수 있지만, 여전히 그 작업은 필요합니다. 올바른 설계 선택은 모듈화된 체인이 아닌 통합 체인 위에서 구축하는 것입니다.
사용자 요구와 JUMP:
-
규모화된 애플리케이션이 필요로 하는 처리량과 컴퓨팅 요구를 산출하세요.
-
Jump는 솔라나가 다른 고객과 협력하는 것을 도우는 중이지만, 솔라나에서 다른 고객을 구축하는 유일한 팀은 아닙니다.
-
솔라나는 많은 고비를 겪어왔습니다. 때로는 자체 정지 버그 때문이었고, 때로는 제3자와의 협업 때문이었지만, 확실한 것은 솔라나 커뮤니티가 그 과정 전반에 걸쳐 지속되어 왔다는 점입니다.
-
솔라나는 계속 존재할 것이며 다음 사이클에서도 훌륭한 성과를 보일 것입니다.
엔지니어를 무시하는 것은 당신 자신의 책임입니다. 우리는 좀 더 현실적이어야 합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@LoganJastremski![암호 조간: 일본 금융 거물 SBI 와 Solana 재단, 전략적 파트너십 체결, 트럼프 미국 상원에 [Clarity Act] 신속 통과 촉구](https://upload.techflowpost.com/upload/materials/articles/20260701/20260701104056138403.jpg?x-oss-process=image/resize,p_50/quality,q_80)
