Architects of Consensus는 보이지 않는 곳에서 세계에서 가장 검증된 고성능 블록체인 스택 인 EOSIO를 개발하고 발전시키는 인물들을 조명하는 데 전념하는 시리즈입니다. 이들은 블록체인 기술의 타원 곡선과 머클 트리를 따라가며 많은 잠재력을 드러내고, 그 지식을 우리와 공유하기 위해 돌아온 용감한 탐험가들입니다.
— Arthur C. Clarke.
“충분히 발전된 기술은 마법과 구별할 수 없다.”
기계와 인간 언어 사이의 주변을 탐색하는 것은 일종의 마술입니다. 컴파일러 이론을 꿈꾸는 블록체인 개발자의 눈으로 보면 시간은 팽창하는 것처럼 보이고 이전에는 볼 수 없었던 커뮤니케이션 방식이 보입니다. Bucky Kittinger와의 대화에서 저는 그에게 있어 최첨단 기술이 갈림길 정원을 산책하는 것과 비슷하다는 것을 깨달았습니다. 그리고 그는 그곳에서 매우 편안해 보였습니다.
우리의 화상 통화가 시작되었을 때, Bucky는 아름다운 기타들이 장식된 벽 앞에 앉아있었습니다. 그의 말투는 미국 남부의 분위기를 뚜렷이 느끼게 했고, 잠시 이야기를 하고 난 후 그가 버지니아의 농경지에 위치한 집에 있는 것과 동등하게 블록체인 기술의 경계에 있다는 것이 느껴졌습니다. 즉, 그는 사이버틱한 풍경에서 가벼운 사이클을 즐기듯이 황소와 어울릴 것 처럼 보였습니다.
젤다의 전설을 통해 얻은 그의 초기 영감에서부터, EOS 커뮤니티에 대한 그의 생각, ARM 아키텍처에 대한 잠재적인 서포트, 혹은 EOS가 어떻게 NatiVM와 함께 “앱 실행 무기 경쟁의 마지막 다리”에서 경쟁할 수 있는지 등 Bucky와 저는 전반적으로 넓은 영역에 대한 대화를 나누었습니다.
Bucky는 2016년부터 베어메탈과 고성능 블록체인 솔루션 사이의 경계를 탐구해 온 합의 수준(Consensus level)의 블록체인 설계자이자 엔지니어입니다. 래드포드 대학에서 컴퓨터 공학을 전공을 수료한 후, Bucky는 버지니아 공대에서 컴파일러 이론 및 컴퓨터 아키텍처 박사 학위를 밟기 시작했습니다. 그는 이후 차세대 블록체인 솔루션을 설계하고 구축하기 위해 Block.one에 합류했습니다. Bucky는 현재 EOS Network Foundation에서 기반 기술의 재탄생 및 재부팅 단계를 위해 수석 엔지니어로 종사하며, EOS를 동급 최고의 Web3 스마트 컨트랙트 플랫폼 및 블록체인 생태계로서 더욱 발전시키는 것을 목표로 하고 있습니다.
근본적으로, 블록체인이 제시하는 문제는 무엇인가요?
저에게 개인적으로 블록체인에서 지속되는 주요 문제 중 하나는 현존하는 솔루션, 지연 시간 문제, 처리량 문제, 사용자 경험 등으로부터 오는 일반적인 실용성입니다. 이것은 대부분의 사람들에게 있어, 보유하고 있는 CPU의 양이나 비용, RAM 가격 및 이러한 유형의 우려로 인한 극단적인 제한 때문에 많은 아이디어와 새로운 솔루션을 실현할 수 없음을 의미합니다.
그리고 그것은 제가 이 문제들이 해결된 것을 보고싶은 더 중요한 영역입니다. 바로 성능, 지연 시간, 그리고 컴파일러 이슈들이죠. 다시 말하자면, 이러한 것들의 비용을 최소화해야 여러분들은 정교하고 세련된 스마트 컨트랙트의 존재를 가져올 수 있습니다. 이는 단순히 토큰을 계정 a에서 b로 전송하고 b에서 c로 전송하는 것 그 이상입니다.
너무 비싸거나, 제 시간 내에 할 수 없기 때문에 현재 존재하지 않는, 블록체인 수준에서 이루어야 할 훨씬 더 많은 것들이 있습니다. 따라서 현존하는 프로그래밍 방식 모델들은 정말 끔찍합니다. 이를 발견하기 위해서 여러분은 정신적으로 체조를 수행해야 합니다. 예를 들어, 만약 제가 이곳의 상태를 잘라내고 저장한 다음 다시 돌아와 재진입 유형의 작업을 수행하면 이것이 어떻게 작동할까요?
그리고 우리가 본 바에 의하면, 별로 좋지 않죠. 그렇죠? 당신은 결국 버그를 만들고 수백만 달러를 잃게 될 것입니다. 저는 그 계층이 훨씬 더 쉽게 경쟁할 수 있게 되어, 더 복잡하고 난해한 시스템들을 구축하는 것이 훨씬 더 쉽고, 최소한의 작업만 수행하는 것이 훨씬 더 쉬워지는 것을 보길 원합니다.
당신이 작업한 더 주목할만한 몇몇 프로젝트는 무엇입니까?
Block.one에서 저는 EOSIO.CDT, EOSVM을 만들고 일반적으로 EOS에 대한 수많은 기초적인 작업들을 수행했습니다. 저는 또한 EOSIO 컨트랙트에 상당한 기여를 했고, 대부분의 핵심 엔지니어들이 그랬던 것처럼 여기, 저기, 그리고 거의 모든 곳에 손을 댔습니다. 그 외에는 아마도 저의 박사학위가 다른 유일한 참고 사항이었다고 생각합니다. 컴파일러 이론, 컴퓨터 아키텍처, 벤치마크 합성 등에 관한 논문 작성이죠.
초기에 무엇이 당신을 DOPS와 EOSIO로 이끌었으며, 또한 무엇이 당신을 계속 여기에 머물게 만들었나요?
처음에 저를 DPOS로 이끈 것은 실용적인 가능성들이었습니다. 제가 항상 보고 싶었던 가장 큰 것은 블록체인의 편재성과 실제 사람들이 일상 생활에서 이 아름다운 기술의 이점을 누릴 수 있는 기술 제품으로 받아들일 수 있는 곳이었습니다.
위에서 언급했듯이, 지연 시간과 처리량은 역사적으로 활용 및 채택과 관련하여 큰 문제였습니다. 그래서 저에게 DPOS는 EOS 및 이를 기반으로 구축된 다른 체인들이 가장 성능이 뛰어나고 확장성이 뛰어난 유형의 솔루션이 되도록 했습니다. 왜냐하면 우리는 다른 어떤 체인보다 하드웨어를 최적화할 수 있기 때문입니다. 우리는 지원하고자 하는 것과 지원하지 않는 유형에 대해 올바른 결정과 최적화를 할 수 있습니다.
이더리움과 다른 많은 체인은 그들의 모델이 블록을 생산하는 소수의 사람들 중 하나가 아니기 때문에 할 수 없는 반면, 그들의 모델은 블록을 검증하는 많은 사람들이 존재합니다. 따라서 그들은 결국에 감자에서 작동할 수 있는 시스템을 설계하게 됩니다. 즉, 고성능 컴퓨팅을 위하여 여러분의 스마트폰이나 국립 연구소에 있는 HPC에서 실행할 수 있습니다. 따라서 그들은 많은 가정을 할 수 없습니다.
감자라고 말씀하신건가요?
(웃음) 맞습니다. 이는 매우 저렴한 하드웨어를 표현한 것입니다. 줄줄이 나오는 감자를 상상해보세요.
반면, EOS는 상대적으로 좋은 하드웨어를 가질 것이라고 말할 수 있습니다. 따라서, 우리가 이러한 사항들에 대해 최적화하면, 우리는 CPU 비용을 최소로 낮추고, 특정 유형의 하드웨어 확장에 대해 최적화하거나, RAM 비용을 낮추거나, I/O 작업들을 중심으로 설계할 수 있다는 것을 알고 있습니다.
이 거의 모든 다른 체인들은 어쨌든 바닥을 향한 이 경쟁에서 끝납니다. 즉, 사용되는 하드웨어가 비싸거나, 맞춤형이거나, 일상적인 사람들이 접근하기 쉽지 않습니다. 따라서 우리는 좋은 하드웨어에 기대어, 이론적인 꿈 대신 현실에 최적화하고 있습니다.
그렇다면 왜 EOS일까요? EOS의 핵심 가치 제안은 무엇이며 무엇을 만들고 싶은가요?
그렇다면 왜 EOS일까요? EOS는 좋은 커뮤니티와 엄청난 잠재력으로 시작되었고 저는 여전히 좋은 커뮤니티가 존재한다고 생각합니다. 지금은 그저 잊혀지고 기대받지 못하고 있습니다. 저희의 초기에 예정되었던 몇 가지 중요한 약속들이 지켜진다면 저희가 구축할 수 있는 놀랍고 굉장한 기반을 구축할 수 있다고 생각합니다.
이는 어느 정도는 기업을 설립하는 것과 비슷하며 이미 특정한 시점에서 관심을 가진 사람들이 있습니다. 우리가 완전히 새로운 생태계로 가서 부트스트랩할 필요가 없다는 이점이 있습니다.
이제 그 신뢰를 회복하기 위해 해야 할 일이 많다고 생각합니다. 이는 바로 지금 진행되고 있는 일입니다. 저희가 사람들이 원하는 일을 계속하고 사람들이 수익을 늘릴 수 있는 좋은 방향으로 체인을 움직이게 하는 동안 나머지는 자연스럽게 따라올 것입니다.
그리고 개인적으로, 저는 아직 마무리 되지 않은 많은 기술들과 기술 방향에 대해 몇 년 동안 마음에 품고 있던 미완성 사업들이 있으며, 여전히 이들이 현실화되길 원합니다.
당신은 EOS가 초기 약속 중 일부를 이행할 수 있다고 언급했습니다. 그 약속들이 어떻게 느껴졌는지 당신은 어떻게 설명하시겠습니까?
제가 느낀 것 중 하나는 편재성(Ubiquity)을 위한 추구였습니다. 편재성 말할 때, 저는 모두를 위한 블록체인, 일상적인 일반 인터넷 사용자를 위한 블록체인, 크립토를 가장 사랑하는 분들을 위한 블록체인을 의미합니다. 저는 여전히 블록체인과 암호화폐의 현재 상황이 초기 단계라고 생각하지만 편재성에 대한 격차를 좁힐 수 있다면 저희는 기술의 실제 이점과 그것이 어디까지 갈 수 있는지를 보게 될 것입니다.
Block.one에서 저희는 너무 많은 다른 방향들로 갔다고 생각합니다. 저는 여전히 EOS가 더 안정적인 체인 중 하나가 준비가 되어 있으며 잠재력이 가장 많은 체인 중 하나라고 생각합니다. 그러나 구체적으로 말씀드리자면, 무언가를 만들 수 있는 진정한 최고의 수준의 프로페셔널 환경의 확장성, 가장 안전하고 수익성이 가장 높은 체인이 되는 것이 제가 개선되길 바라는 모든 분야입니다.
당신이 거주하는 곳의 크립토 현장이나 개발자 커뮤니티는 어떻습니까?
저는 버지니아 주 블랙스버그(Blacksburg) 근처에 있는 크리스천스버그(Christiansburg)에 살고 있습니다. 크립토 현장은 상당히 다양합니다. 완고한 이념적 크립토 사람들, 현실 세상과 단절한 사람들, 순수하게 기술적인 사람들 및 위의 모든 것들이 종합된 분들이 있습니다.
이렇게 다양한 종류의 사람들이 존재하는 가장 큰 이유는 버지니아 공대(Virginia Tech)입니다. 아시다 시피 이곳은 시골이며 농사일 밖에 없습니다. 따라서 농장을 운영하거나 블록체인을 만드는 것 외에는 할 일이 많지 않습니다.
버지니아 공대는 상당히 큰 대학이기 때문에 비교적 다양한 그룹의 사람들이 모입니다. 크립토 커뮤니티의 관점에서 볼 때 크리스천스버그, 블랙스버그 지역은 아직 초기 단계라고 생각하지만, 그곳에 있는 사람들은 열정적으로 살고 있습니다. 이미 그 지역에서 Block.one에 합류한 사람도 있고, 다른 주에서 Block.one에 합류한 사람들도 있습니다. 그래서 이제 그들은 그들만의 이니셔티브와 제품을 추진하고 있으며 이는 정말 멋진 일입니다.
당신의 사연은 무엇인가요? 블록체인을 향한 여정은 어떠셨나요?
저는 버지니아 주 크리스천스버그의 작은 목장에서 자랐습니다. 친구의 NES에서 젠다의 전설을 플레이하고 그 게임을 정말 좋아했기 때문에 컴퓨터 공학에 입문했습니다. 그리고 저는 이것을 언젠가는 직접 만들 방법을 찾아야겠다고 생각했습니다. 마치 말 그대로 젤다의 전설 게임을 만드는 것처럼 말이죠!
저는 가난하게 자랐습니다. 그래서 프로그래밍을 배우기 시작한 초기의 많은 나날들을 점심시간이나 방과 후에 혼자 학교 컴퓨터를 이용하며 보냈습니다. 또한 책도 살 형편이 안되어 처음에는 어려움을 겪었습니다.
초등학교 후반이나 중학교 초반 무렵이었습니다. 아마 90년대 초중반 정도였을 것입니다. 저는 학교에 갔고 그당시 버지니아 공대에 연결된 큰 메인프레임을 가지고 있었습니다. 저는 그것을 탐험하고 글자와 숫자가 떨어지는 진부한 게임을하고 있습니다. 그 당시에는 매우 오래된 기술인 gzhhhh gzhhhh gzhhhh를 사용한 커다란 도트 매트릭스 프린터가 있었습니다.
하지만 그 기계에 싫증이 나고 매일 파일 시스템을 검색하다 보니 이상한 기본 인터프리터(interpreter)를 발견하고 기본 언어로 프로그래밍하는 방법을 알아내기 시작했고 그것이 제게는 끝의 시작이었습니다. (웃음)
중학교 때 도서관의 컴퓨터를 업그레이드 시켜서 사용하기 시작했으며, 하다보니 system32 폴더에 숨어있는 QBasic을 발견하고 재미있는 QBasic 프로그램을 사용하기 시작했습니다. 그 당시 인터넷은 검색하기에 많은 어려움이 있었습니다. 그때 저의 선생님 한분 께서 QBasic을 프로그래밍하는 방법에 대한 책을 저에게 주셨습니다.
저는 모든 종류의 무작위적인 것들을 만들었습니다. 하지만 문제는 엄청나게 느려서 젤다의 전설을 만들려는 시도는 불가능했습니다.
그래서 당신이 컴파일러 이론에 빠져들게 된 것이군요 그렇죠? 너무 느리다고 생각했기 때문에 말이에요.
네, 너무 느렸고 실제로 그랬던 것 같습니다. 왜냐하면 저는 더 많은 성능 그리고도 더 많은 성능을 얻기 위해 끊임없이 움직였기 때문입니다. 저는 일종의 딥 엔드에서 벗어나 QBasic에서 어셈블러로 뛰어 들었습니다. 왜냐하면 컴퓨터에 있는 유일한 다른 것은 Microsoft 어셈블러였기 때문입니다. C 컴파일러나 C++ 컴파일러가 없었기 때문에 저는 당연히 베이직에서 어셈블리(assembly)로 가야한다고 생각했습니다. 그래서 어셈블리를 작성하기 시작했고 얼마 지나지 않아 저는 Linux를 발견했고, 거기에 C 및 C++ 컴파일러가 있다는 것을 알게 되었고, C를 배우기 시작했습니다. 저는 이후 계속 그런 길을 걸어왔습니다.
당신의 가족들은 이 모든 것들을 어떻게 여기셨나요?
저희 가족들은 이를 대단한 일로 여기지 않았습니다. 제가 하고 있는 건 그냥 버키가 한 괴상한 일 정도였습니다. “그는 자라서 언젠가는 진짜 일을 할 거야”, “그는 조금 하다 말거야”, “걱정하지 마세요. 단지 성장하는 단계 일뿐입니다. 그는 성장할 것입니다.” 나는 그것에서 벗어나지 못했습니다.
결국 저는 고등학교를 졸업하고 아버지 밑에서 4년 동안 일을하며 받은 돈의 대부분을 모아서 대학교를 졸업하고, 이후에 즉시 대학원에 진학했습니다. 이건 좀 이상한 길이었습니다.
대학교는 어디를 나오셨나요?
저는 크리스천스버그에서 5분거리에 있는 래드포드 대학교에서 과정을 마쳤습니다.
어떻게 컴퓨터 공학을 전공하면서 박사 과정까지 밟게 되셨나요?
저는 대학교 과정에서 컴퓨터 아키텍처 및 컴파일러 교수님들(Dr. Ian Barland와 Dr. Ned Okie)과 친구가 되었습니다. 교수님들은 계속해서 저에게 박사 과정을 밟을 생각이 없는지 물어보셨습니다. 그리고 저는 말했습니다. “아니요, 정말 아닙니다.” 알다시피, 저는 버지니아에서 온 농장 아이입니다. 이것으로 이미 충분합니다. 이것은 우리 가족의 기준에서는 미친 것입니다. 그래서 지속적으로 괜찮다고 말했습니다. 하지만 그분들은 지속적으로 제게 박사 학위를 받아야 한다고 설득하셨습니다. 그것은 제게 정말로 자극이 되었고, 유일한 이유였습니다.
그래서 저는 버지니아 공대에서 아키텍처 및 컴파일러 관련 현업에서 근무하고 계시는 교수님을 만나 한 번의 인터뷰를 가졌습니다. 교수님은 “좋아, 월요일에 올 수 있니?”라고 말했습니다. 그리고 저는 “좋아요, 괜찮습니다!”라고 대답했습니다.
그래서 3년 동안 당신은 컴파일러 이론만을 달고 사신건가요?
예. 그리고 컴퓨터 아키텍처도 마찬가지였습니다. 왜냐하면 제가 수행한 작업의 또 다른 부분은 프로세서 확장을 설계하고, 코드 변환을 설계하고, 다양한 종류의 특이한 아키텍처에 대한 최적화를 설계하는 것이기 때문입니다.
좋습니다. 당신이 컴파일러 이론을 다루었으니, 저희에게 컴파일러 이론을 간단하게 알려주세요.
(웃음)
좋아요, 하지만 진지하게, 컴파일러 이론에서 박사 학위를 받으면 실질적으로 어떤 결과가 나올까요?
그래서 제가 주목한 한 가지는 에너지 수확 시스템 또는 전력 오류가 많은 유형의 시스템을 위한 하이퍼 임베디드 IOT 프레임워크에서 연산을 수행하고 특정 시점에서 완전한 실행을 보장하는 방법이었습니다. 이것이 제가 당시 Dan(Larimer)과 대화할 때마다 하이퍼 임베디드 시스템과 스마트 컨트랙트 실행 레이어의 어느 정도 유사성을 본 또 다른 이유입니다. 그리고 저는 그 첫 회의 이후로 같은 동일한 비전들을 가지고 있었고 이러한 많은 것들을 원했습니다.
전원 장애(power fault)가 무엇이며 그 개념이 블록체인과 관련이 있는 이유를 설명해 주실 수 있나요?
만약 여러분이 에너지 수확 시스템이나 전원을 무작위로 차단하는 시스템이 있는 경우에, 당신이 다시 시작하는 경우 처음부터 시작해야하며 계속 진행할 에너지가 부족할 경우 현재 진행 중인 연산이 효과적으로 중단됩니다.
따라서 이러한 것들의 유형들과 관련된 문제는 수많은 이러한 작은 센서들 혹은 나노 IOT 장치들인데, 그들은 이러한 프로그램 플로우의 작은 청크들 위에서 가동될 것입니다. 그리고 여러분들은 그것들이 그냥 끊어지는 것을 원하지 않을 것입니다. 왜냐면 여러분이 시시포스 같은 상태에 이르게 될 것이기 때문입니다. 이건 바위를 언덕위로 계속 올리려고 하는 행동과 같습니다. 하지만 그것은 끝내 사라져 버리고 결코 바위를 언덕위로 올릴 수 없습니다. 그래서 여러분은 여러분이 하려고 하는 일의 이 부분을 결코 끝내지 못합니다.
그것은 정체(Stagnation)라고 불립니다. 정말 큰 문제입니다. 그래서 저는 그것을 3~4개의 다른 방법으로 해결했습니다. 어떤 것은 하드웨어로, 어떤 것은 완전히 컴파일러가 지시하는 것으로 해결했습니다.
그래서 제 목표는 그 중 일부를 EOSIO로 가져오는 것이었지만 실제로는 할 일이 너무 많고 시간이 충분하지 않았기 때문에 실제로 달성하지 못했습니다. 또한 버지니아 공대에서 제가 설계한 도메인별 최적화들이 많이 있었는데, 이 최적화 또한 아직 완벽하게 일어나지는 않았지만 항상 가져오고 싶었습니다.
왜냐하면 저에게 있어, 실제로 할 수 있는 실질적인 일은 블록체인에 존재하는 더 긴 실행 프로세스를 효과적으로 만드는 것이기 때문입니다. 블록체인상에서 보다 일반적인 유형의 개발 패턴을 시작합니다. 그래서 모든 사람들이 끊임없이 추상적인 모델들을 떠올려야 하는 틈새와 어려운 일은 덜합니다. 음, 저는 이 연산을 할 시간이 0.5초 밖에 없습니다. 제가 그걸 어떻게 하는 거죠? 어떻게 하면 제가 정신적으로 들어가고, 이 프로그램을 분할해서 이 작은 창에서 효과적으로 실행할 수 있을까요?
그래서 제가 하고 싶었던 것 중 하나는 더 오래 실행되는 연산들이 프로그램을 통해 완전히 자연스럽게 존재할 수 있도록 하는 것이었습니다. 그렇죠? 엔지니어가 그곳에서 해야할 일은 아무것도 없습니다.
따라서 우리가 프로그램과 스마트 컨트랙트 실행을 실행하는 데 사용할 수 있는 에너지의 정체와 작은 버퍼를 살펴보면, 유사점들은 둘 다 제어 흐름 중에 갑자기 “무작위로” 차단된다는 것입니다. 스마트 컨트랙트의 경우 이는 상태 저장 패턴을 명시하고 테이블에 상태 저장 또는 작업 반환으로 다시 전달하고 재진입 작업 또는 장기 실행(논리적으로) 작업을 생성하려고 하는 등 다양한 수준의 효율성으로 해결되었습니다.
그렇다면 컴파일러에서 작업하는 이유는 무엇인가요?
저는 그저 낮은 수준의 시스템과 컴파일러를 좋아합니다. 그래서 여러분이 정말 하급자라고 생각된다면 운영 체제나 컴파일러에 입문하는 것이 더 쉬울 것입니다. 그리고 저는 컴파일러를 선택했습니다. 왜냐하면 컴파일러는 마법과도 같았기 때문입니다. 사람이 읽을 수 있는 것을 놀라울 정도로 최적화하고 멋진 것으로 변화시킵니다.
우리에게 EOSIO CDT(Contract Development Toolkit)에 대한 당신의 작업과 당신이 그것에 대한 점검이 필요하다고 생각하는 이유에 대해 알려주시기 바랍니다.
네, 이제 Mandel에서는 단지 CDT인 EOSIO.CDT는 컨트랙트 개발 툴키트입니다. 따라서 그것은 툴체인, 컴파일러 링커, 라이브러리를 생성하는 모든 것, EOSIO 웹 어셈블리(Wasm)에 대한 다양한 종류들, 최적화, EOSIO에 특정한 코드를 생성하기 위한 언어 확장, 특정 블록체인 구성에 대한 추상화, 그리고 디버깅 및 테스트를 위한 라이브러리 서포트와 EOSIO 블록체인 작업을 위한 실제 기본 라이브러리 세트입니다.
그래서 저는 CDT를 만들 때 몇 가지 목표를 세웠습니다. 그 목표들은 믿을 수 없을 정도로 성능이 좋고, 안전하고, 사용하기 쉽고, 커뮤니티 참여라는 측면에서 확장된 능력을 가지고 그곳에 도달하고 싶었습니다.
CDT와 함께 소개된 몇 가지 큰 이슈들이 존재합니다. 첫째, 저는 그것이 단지 C++만 되는 것을 원하지 않았습니다. 그 당시에는 C++가 유일하게 사용 가능했고 그 이유로 저는 그것을 선택해야만 했지만 언젠가는 프로젝트를 좀 더 추상적으로 마이그레이션할 수 있기를 원했습니다. 다른 문제는 유용성과 사용 편의성에 관한 것이었습니다. 다시 한 번 말씀 드리지만, 저희는 정말로 그곳에 도달하지 못했습니다. 그 당시에는 도구에 초점을 맞추지 않았습니다.
CDT 작업의 대부분은 3년 동안 저의 자체적인 여가 시간에 제가 진행했기 때문에 그 공간에서 어떤 일을 하는데 있어서 동기부여를 얻는 것은 정말 어려웠습니다. 저는 항상 이런 더 근본적인 것들을 시작하는 것과는 반대로 따라잡기 위해 노력했습니다.
따라서 당신은 ENF의 일원으로서 정말로 그일에 전력을 다하기를 원하는 팀과 함께 이 일에 다시 참여하게 되어 많이 흥분될 것 같은데요, 그것은 당신에게 어떤 모습이 될까요?
네, 물론입니다. 제가 ENF에 왔을 때 Yves(La Rose)와 처음 이야기했던 주요 내용 중 하나는 재생(rebirth)과 재부팅(reboot)의 개념이었습니다. 저희가 잘못했거나 그저 하지 않은 일들을 먼저 고치는 것은 좋은 방향으로 나아가기 시작하는 평행 세계를 갖는 것과 같습니다. 지금으로부터 4년 후, 저희는 지금과는 완전히 다른 위치에 있을 것입니다. 그래서 저는 ‘그래, 이것이 내가 꼭 가봐야 할 곳이다’라고 생각했습니다. 저는 실제로 제가 이전에 집중했던 것과 같은 종류의 것들에 관심을 갖는 뛰어난 수준의 사람들이 있다는 것에 대해 매우 흥분했습니다.
그것은 조금 더 포괄적이고, 제 생각에 일반적으로 사람들은 여러분들이 생태계를 가진다면(그게 생태계가 맞죠?) 그것은 여러분들이 공급하고 그게 전부인 단지 작은 하나의 구성요소가 아니라는 것을 깨닫는 것 같습니다. 여러분은 그 생태계를 구축하기 시작해야 합니다. 그렇게 하지 않으면 모든 것이 증발하게 될 것입니다. 그리고 그곳이 우리가 도달했던 지점입니다.
제가 Block.one에서 일하면서 생각해낸 비유가 있습니다. 제가 여전히 좋아하는 것입니다. 만약 여러분이 세상에서 가장 빠른 차를 만들었는데 아무도 운전하지 않는다면, 당신은 사실상 세상에서 가장 느린 차를 만든 것입니다. 그것은 시속 0마일을 유지하기 때문입니다. 그래서 제게는 그것이 문제였습니다. 저희는 매력이나 효용이 제한적인 이러한 다른 많은 부수적인 것들에 초점을 맞추었습니다.
그렇다면 당신이 제안한 CDT의 후속 제품인 ANTLER(ANother TransLator Environment and Runtime)에 대해 이야기 해주실 수 있나요?
ANTLER와 CDT의 가장 큰 차이점 중 하나는 항상 C++ 만 존재하는 것이 아니라는 것입니다. 그것은 여전히 C++를 가질 것이지만, C, Go 그리고 아마도 Rust 또한 지원할 것입니다. Rust는 아마 빠르게 따라올 수 있을 것입니다. 저는 뒤쪽에서 이런 것들을 상당히 많이 다루었습니다.
그래서 저는 ANTLER와 관련하여 앉아서 툴링 생태계와 어느정도로 사람들이 받아들일 수 있도록 효과적으로 구축된 일련의 것들(저는 중심성이라 말하고 싶진 않습니다.)을 가질 수 있는 방법을 디자인 하고 싶었습니다.
단지 누군가가 컴파일러를 만든다고 해서, 저에게는 그것이 정말로 충분히 좋은 것은 아닙니다. 정말 좋은 최적화된 컴파일러를 만들어야 합니다. 그리고 그것은 제가 생각하는 어떤 팀보다도 훨씬 더 많은 노력이 필요합니다.
그리고 저희는 그것이 필요하지만, 그 후에는 어떻게 될지를 생각해 봐야겠죠? 그들은 디버거 서포트가 필요하고, 프로파일러 서포트가 필요하며, 존재해야 하는 삶의 모든 이러한 자질들을 필요로 하며, 이는 그들이 스스로 만들어야만 한다는것을 의미합니다.이는 다시 한 번 완전한 악몽입니다.
ANTLER의 큰 목표 중 하나는 코드 생성, 링크, 옵티마이저 및 디버거, 프로파일러 지원 등의 개념을 추상화하는 것입니다. 따라서 이러한 소규모 팀들이 다른 남아있는 사항들에 대한 골칫거리 없이 쉽게 새로운 언어를 만들 수 있습니다.
또한 이러한 언어를 추상화하고 보다 복잡한 시스템을 쉽게 구축할 수 있는 패키징 시스템과 훨씬 간단한 구축 시스템을 갖추고 개발자들이 커뮤니티 소유 패키지를 통해 더 많은 코드를 사용할 수 있기를 희망합니다.
오늘날 더 큰 문제 중 하나는 스마트 컨트랙트 개발자가 어려운 C++에 매우 익숙해져야 한다는 것입니다. 언어 전체에 많은 함정이 있으며 이는 힘든 여정이될 수 있습니다, 따라서 지원되는 언어 세트를 확장함으로써, 여러분들은 개발자가 이러한 언어들 중 하나에 대해 더 잘 알고 관련 덫과 함정들에 대한 이해를 얻을 수 있는 더 나은 기회를 제공합니다.
희망적인 것은 그들은 이미 일부 언어의 전문가라는 것입니다. 따라서 그들이 전문성을 가지고 있는 것이 무엇이든 간에 그들을 포착하고 이를 활용할 수 있다면, 매우 다양한 스마트 컨트랙트 생태계를 만들 가능성이 훨씬 더 높아집니다. 그들이 언어 X에 대한 그들의 지식을 가지고 와서 Wasm의 전문가가 되어야 하는 것과는 달리, 그들은 디버깅을 위한 dwarf 포맷, 정적 분석 전문가, 연결의 전문가가 되어야 합니다.
기본 언어의 전문가가 아니면 직면하는 더 큰 문제 중 하나는 버그와 수백만 달러의 손실입니다. 그래서 결국 여기서 목표는 사람들이 이러한 시스템을 구축하고 디버거, 프로파일러, 최적화된 컴파일러를 받아들이고 신경 쓰지 않는 부분을 추상화할 수 있도록 하는 것입니다. 그들이 신경써야 하는 유일한 것은 그것의 근본적인 언어적 측면입니다.
일단 여러분이 그것을 얻게되면, 사람들을 온보딩하는 것이 문제인 그 지점에서 일이 상당히 쉬워지기 시작할 것입니다. 여러분은 어떤 언어에 유창하신가요? 좋아요, 당신은 OCaml에 능숙합니다. 커뮤니티에서 OCaml 컴파일러를 작성했습니다. 이 언어 사양을 OCaml로 지정하면 해당 언어를 가져와서 컴파일러가 단지 작동할 것입니다. 그것이 ANTLER의 높은 수준의(그리고 고상한) 목표입니다.
아키텍처에 이야기가 나와서 질문드립니다. 당신은 Wasm(Web Assembly)을 사용하는 EOS-VM을 설계하셨는데, 저는 당신이 그곳에서도 새로운 시스템을 만드는 것을 고려중이라고 들었습니다?
네, 그래서 제가 하고 싶은 것은 x86-64(AMD64는 이에 사용되는 다른 이름입니다)를 중간 표현으로 효과적으로 사용하는 NatiVM 런타임이라고 부르는 것입니다. 이는 우리가 현재 Wasm을 사용하는 방법과 같습니다. 이는 현재 Intel 및 AMD 장치에서 사용되는 핵심 아키텍처 또는 명령어 세트입니다.
x86-64로 이동하는 데에는 몇 가지 이유가 있습니다. 하나는 40년 동안의 개발되었다는 것입니다. 개발자의 관점에서 볼 때 저희는 이러한 다양한 유형의 도구, 정적 분석, 동적 분석, 프로파일링 도구와 관련해서 다시 개발할 필요가 없습니다. 저희는 업계 표준 기술을 받아들일 수 있습니다. 이는 이미 작성되었습니다. 저희는 가서 아무것도 할 필요가 없습니다. 우리는 단지 이것을 무료로 사용할 수 있습니다. 그래서 그것은 하나의 큰 구성 요소입니다.
또 다른 요인은 Wasm의 기본 성능 문제이며, 제가 보는 Wasm에 대해 인식하는 몇 가지 문제는 앞으로 표준의 움직임과 추진력 측면에서 볼 수 있습니다.
Wasm의 또 다른 문제는 저희가 얻을 수 있는 성능의 상한선이며, 이는 컴파일러, 존재하는 툴 체인(toolchains)에서 발생한 것이며 저희가 생산할 수 있는 최소한으로 추상화된 아키텍처로 할 수 있는 일의 전반적의 한계에서 나온 것입니다.
따라서 x86-64의 경우, 레지스터 기반 3개 주소 시스템 모델에 매우 적합하며, 이는 명령어 세트가 (최대) 결과, 피연산자(operand) 1 및 피연산자 2, 레지스터 및 메모리 위치를 활용하기 위한 다중 주소 지정(multiple addressing) 모드를 가지고 있음을 의미합니다. Wasm은 0-address 스택 기반 시스템의 모델에 적합하므로, 이러한 시스템 간의 세부 정보가 손실되고, 스택 기반 시스템으로 인해 레지스터 할당이 어렵고 시스템을 변환하기 위해 작업하는 것은 매우 복잡한 일이며 여전히 별칭 분석 문제(alias analysis issues)으로 인해 특정 수준 이하로는 얻을 수 없습니다. (유형 정보의 결여)
그래서 Wasm은 레지스터를 사용하지 않는 건가요?
네. Wasm을 사용하면 그 안에 있는 모든 것이 효과적인 메모리 작업입니다. 명령어로 인코딩되는 즉시 작동하거나 메모리 로케이션(memory location)이며, 이는 메모리 주소 또는 합성 스택(synthetic stack) 또는 글로벌 인덱스입니다. x86-64와 관련하여 레지스터라고 하는 항목이 있습니다. 이는 레지스터에 항목을 추가하고, 읽고, 기록하는 한 사이클의 작업입니다. 이것은 바로 현대 아키텍처에서 높은 성능이 나오는 부분입니다.(또한 새로운 데이터를 채우기 위해 해당 레지스터를 유출하고 최적으로 할당하지 않아 레지스터가 손실될 수 있는 부분이기도 합니다.)
따라서 시스템의 레지스터를 활용하는 것은 항상 최적화해야 하는 큰 문제입니다. 문제는 Wasm에 그런 개념이 없다는 것입니다. 결국 발생하는 이러한 일은 단지 메모리 읽기 및 쓰기가 된다는 것입니다. 이는 컴파일러와 관련하여 많은 기술적인 세부사항 및 컴파일러가 왜 좋아하지 않는지에 대한 설명이 없고, 그리고 결국에는 이를 최적화하는 데 몇 가지 문제가 발생하게 됩니다.
여전히 존재하는 또 다른 문제는 표준 자체가 이러한 확장을 얻는 측면에서 굉장히 느리게 움직이고 있다는 것입니다. 따라서 이것은 Wasm 또는 우리의 Wasm의 채택에 있어 또 다른 지속적인 문제였습니다. 이러한 확장은 SIMD, 예외, 동적 모듈 등과 같은 것일 수 있습니다.
저희가 vanilla Wasm과 가깝게 지내면서 많은 것을 얻었던 이러한 사고방식이 항상 존재했습니다. 설명서가 업데이트되고 승인될 때까지 기다려야 한다는 문제 또한 존재합니다. 심지어는 성능상의 이유, 개발자의 이유, 노드 운영자의 이유 등으로 우리가 있길 원하지만 규격에 없는 것들이 있습니다.
저희가 반드시 해야 할 일들에 대한 리스트가 있지만 저희는 할 수 없습니다. 그 이유는 그러한 것들이 단지 Wasm의 일부가 아니기 때문입니다. 그리고 우리가 계속해서 이러한 것들을 기다려야 한다면, 저희가 구현하기 전에 블록체인 자체가 죽게 될 것입니다. 문제는 블록체인 기술이 Wasm이 앞으로 나아가는 속도에 비해 너무 빠르다는 것입니다.
그렇다면, 당신이 제안한 NatiVM 솔루션은 새로운 표준이 될 수 있나요?
네.
NatiVM에 대한 간략하게 소개해주실 수 있나요? 그리고 블록체인 업계 전반에서 당신이 그 사용을 어떻게 보고 있는지 궁금합니다.
가장 큰 것 중 하나는 이것이 저희가 제공하는 개방형 표준이 될 것이라는 것이며, 미래에는 다른 사람들이 그 방향에 대한 의견을 제시하고 방향에 대한 영향력을 갖게 될 것입니다.
더 큰 구성 요소는 x86-64의 적절한 부분 집합이 될 것입니다. 미래에는 (희망적으로)우리가 결정론적 ARM을 지원하겠지만, 지금은 결정론적 x86-64에 집중해야 합니다. 도구를 구축하거나 라이브러리 지원을 구축하려는 모든 사용자는 가서 작성하거나 생각해 낼 필요가 없습니다.(이러한 지침을 어떻게 인코딩 또는 디코딩할 수 있을까요?) 그런 종류의 것은 이미 존재합니다. 그들은 단지 런타임 및 검증 시스템을 위해 X86-64용 기존 제품을 사용할 수 있습니다. 기본적인 컴파일러와 런타임은 이 하위 집합에 초점을 맞춰야하는 유일한 것입니다. 바이너리 형식은 이 표준이 무엇인지, 이 앱 자체에 어떤 섹션이 있는지, 그리고 우리가 원하고 유지하기를 원하는 다양한 섹션에 대한 범위 내에 있습니다.
이것은 하나의 구성 요소이며, 두 번째는 더 많은 VM(가상 머신) 레이어입니다. 메모리 관리는 어떤 것 같나요? 메모리 관리 시스템은 운영 체제와 함께 어떻게 매우 효율적인 방식으로 작동하나요? 어떻게 장담할 수 있죠?
저는 그곳에 앱 개발자를 위한 안전과 보안을 위한 것들을 준비했습니다. 예를 들어, 자동화된 저비용의 스택 카나리아와 같은 것들이며, 만약 무언가를 잘못 작성하면 그것은 실패할 것입니다. 이는 온라인에서 공격을 받거나 누군가가 많은 돈을 갈취하지 못하도록 하기 위한 것입니다.
NatiVM의 측면에서는 어느 정도 진척되어있나요? 당신은 그것이 다 보이나요?
네, 현재 저는 어떠한 사각 지대도 없습니다. 모든 것이 거기에 있습니다. 저는 비트와 조각과 추상화된 것이 어떻게 생겼는지에 대해 많은 것을 알고 있지만 여전히 V1에 포함되어야 하는 지침이 무엇인지 정확히 파악중에 있습니다.
저는 그곳에서 제가 무엇을 원하는지 알고 있습니다. 하지만 초기 SIMD도 포함하고 싶어서 고민하고 있습니다. Wasm의 또 다른 이슈는 암호화 기능에 많이 사용되는 SIMD 명령어와 같은 것입니다. Wasm으로 달성할 수 있는 최대 비트 폭은 128비트입니다. 따라서 SSE와 같은 “표준” Intel 또는 AMD 익스텐션들이 있으며 여기에는 128, 256 및 512 비트 오퍼레이션들이 있습니다. 블록체인이 활용할 수 있는 다른 특정 익스텐션 외에도 말이죠.
목표는 다음과 같습니다. 사람들이 x86-64의 난해한 SSE 명령어를 작성하며 많은 시간을 들인 최적화된 많은 암호화 기능을 받아들일 수 있어야 합니다. 성능과 구현의 안전성을 위해 이러한 작업을 수행하는 데 많은 가치가 있습니다. 이미 작성되고 테스트되었습니다.
제가 본 것은 언어가 그런 종류들을 지원하는 경우, 그것들을 추상적인 방식으로 지원한다는 것입니다. 즉, 언어는 그것들을 특별한 것으로 노출해야 하고 그런 것들을 해결하기 위해 많은 노력이 필요합니다. 그리고 이것은 일종의 격변입니다. (다음 버전에서는 반드시 이를 지원해야합니다.) 아시다시피, 앞뒤로 많은 것들이 있습니다.
제가 다루지 않은 Wasm의 가장 큰 이슈 중 하나는 결정론입니다. 저희가 가지고 있는 대부분의 “백엔드”로 결정론을 진정으로 보장할 수 없습니다. 이는 우리가 물리적 시스템에서 실행되는 생성된 코드의 유효성을 검사하고 있지 않기 때문입니다. 그러나 NatiVM의 놀라운 결과는 우리가 x86-64를 순전히 결정론적인 x86-64로 검증한다는 것입니다. 이것은 저희가 실행의 루트 수준의 결정론을 보장할 수 있음을 의미합니다.
따라서 SSE 및 기타 익스텐션들을 지원하는 것은 이것이 블록체인이라는 점을 고려할 때 큰 사항인것 같습니다.
네, 이것은 일반적으로 컴퓨터 공학에서 벡터 명령이라고 부르는 명령입니다. 이는 매우 큰 데이터 세트를 허용하고 그 안에 있는 여러 데이터 청크에 대해 하나의 작업을 효과적으로 수행할 수 있습니다.
따라서 해당 256비트 레지스터에 4개의 64비트 값들이 포함된 경우 하나의 작업을 수행할 수 있지만, 동일한 작업으로 이 네 가지 작업을 동시에 수행할 수 있습니다. 이는 GPU가 작동하는 방식과 동일합니다. GPU는 매우 큰 레지스터에 대해 하나의 연산을 효과적으로 수행하며 연산 대상은 큰 matrix 또는 벡터입니다.
이러한 명령어들은 벡터 많은 벡터 작업을 수행 하기 때문에 암호화 시스템에서 매우 유용합니다. 따라서 이러한 기능을 사용하면 성능이 4배, 5배 또는 10배 까지도 향상될 수 있습니다. 그래서 이런 것들을 갖는 데에는 많은 유용성이 있습니다.
두 번째로 intel이 있습니다. 저희가 앞으로 나아가면서 명령어 세트에 점점 더 많은 크립토 명령어를 추가하게 되는데 이것은 Wasm과 같은 것에 절대 추가되지 않을 것입니다.
따라서 기본 하드웨어 자체가 실제로 명령어를 지원하지 않는다고 가정해 보겠습니다. 이는 완전히 문제 없습니다. 우리는 해당 작업을 이어받아 의미 체계를 에뮬레이트하는 “명령어” 버전을 효과적으로 주입할 것이므로, 하드웨어가 512 비트 작업을 지원하지 않더라도 문제가 되지 않습니다. 256 비트 연산을 지원할 수 있습니다. 우리는 단지 그것들을 반으로 나눠서 평소처럼 작업하도록 합니다.
또 다른 주목할 사항은 일반적인 x86-64 명령어로 컴파일하는 것 자체가 엄청난 일이라는 사실입니다. 저는 이 NatiVM 관리 시스템 외부에서 실행되는 순수 네이티브 빌드 코드와 비슷한 오버헤드로 앱을 컴파일하고 실행할 수 있어야 한다는 것을 다른 사람에게 알리는 것은 어렵지 않을 것으로 생각합니다.
ARM 아키텍처와 x86-64를 바이너리로 변환하는 방법에 대해 조금 더 이야기해주실 수 있나요?
네, 물론입니다. 분명히 ARM은 어느 시점에서 일어날 크고 빛나는 일입니다. 저는 아직 몇 년이 남았다고 생각하지만, 사람들은 전망이 좋지 않기를 원할 것이라 생각합니다. 그렇다면 우리는 x86-64 아키텍처에서만 실행할 수 있는데, 그것은 꽤 제한적입니다.
결정론적 x86-64 앱의 유효성 검사 단계에서 우리는 먼저 유효성을 검사한 다음, 일정 시간 “shotgun” 바이너리 재작성기를 사용하여 x86-64를 ARM64로 변환합니다. 이것은 우리가 하위 집합만 지원하고 범용 시스템보다 훨씬 더 많은 가정을 할 수 있기 때문에 합리적으로 어리석은 재작성기가 될 것입니다. Alexis Engelke, et al.는 최소한의 성능 손실로 x86-64에서 ARM64로의 변환 간에 최적화 친화도가 우수함을 보여주었습니다.
이는 좀 큰 사항으로 보이는데, EOS의 미래 경쟁력에도 어느정도 해당되는건가요?
당연한 사항입니다. 저는 NatiVM에 대한 사항이 앱 실행을 위한 군비 경쟁의 마지막 단계라고 생각합니다. DB와 그 주변에 아직 개선해야 할 다른 영역이 있지만, 실행 비용을 최소화할 수 있습니다. 우리는 표준을 우리 스스로 소유할 수 있으므로 시간이 지남에 따라 적응하고 변경할 수 있으며, 더 나아가 우리가 다른 아키텍처와의 호환성 레이어를 확실하게 확보하는 것은 EOS의 미래 경쟁력에 도움이 됩니다.
블록체인을 기반으로 구축하려는 사람들에게 어떤 조언을 하시겠습니까?
제가 줄 조언은 대부분의 사람들이 예상하는 것보다 조금 더 높은 수준입니다. 먼저 애플리케이션을 올바르게 빌드하는 데 집중하세요. 즉. 응용 프로그램의 전체 로직이 견고하고 잘 테스트되었는지 확인하시기 바랍니다. 스마트 컨트랙트와 DApp 코드가 올바른지 확인한 후에는 CPU, RAM 또는 NET 문제에 맞게 최적화하는 데 집중할 수 있습니다.
그러나 우선 프로젝트를 시작하는 것이 가장 중요합니다. 저에게 “나는 이런 훌륭한 아이디어가 있어, 하지만…” 이라고 말하는 사람들을 많이 알고 있는데, 이 사람들은 좋은 엔지니어지만 블록체인 개발의 특성 때문에 프로젝트를 시작조차 하지 못합니다. 따라서 질문을 많이 하고 일단 시도하시기 바랍니다.
당신과 이야기를 나누어 정말 기쁩니다 Bucky! 이곳에 EOS의 미래 경쟁력 있습니다!
저야말로 정말 기뻤습니다. 이러한 내용들에 대해 이야기 하는 것은 항상 재밌죠. 저는 EOS가 매우 증명된 미래를 맞이할 것이라고 생각합니다.(웃음)
만약 여러분이 이번 Architects of Consensus를 재미있게 보셨다면, 우리가 EOS와 EOSIO를 발전시키기 위해 지속적으로 노력하는 세계적 수준의 개발자들의 눈을 통해 볼 수 있는 블록체인의 신비에 대해 더 깊이 파고들 것이라는 점을 알아두시기 바랍니다.
저희의 소셜 채널들에 가입하고 대화에 참여하세요! 지속적으로 블로그를 주시하시고, 메일링 리스트에 가입하셔서 이와 같은 기사들이 배포될 때마다 가장 먼저 만나보시기 바랍니다!
EOS 네트워크
EOS 네트워크는 거의 수수료가 없는 트랜잭션의 결정론적 실행을 위한 저지연, 고성능, 확장 가능한 WebAssembly 엔진인 EOS VM으로 구동되는 3세대 블록체인 플랫폼으로, 최적의 web3 사용자 및 개발자 경험을 가능하게 하기 위해 특별히 제작되었습니다. EOS는 EOS 네트워크 재단(ENF)을 통해 도구 및 인프라에 대한 다중 체인 협업 및 공공재 자금 조달의 원동력 역할을 하는 EOSIO 프로토콜의 플래그십 블록체인 및 금융 센터입니다.
EOS 네트워크 재단
EOS 네트워크 재단(ENF)은 EOS 네트워크의 성장과 발전을 장려하기 위해 재정 및 비재정적 지원을 조정하는 비영리 단체입니다. ENF는 EOS 네트워크의 허브이며, EOS의 조정된 미래를 계획하기 위해 긍정적인 글로벌 변화를 위한 힘으로 탈중앙화의 힘을 활용합니다.
