플랫폼은 어떻게 성공합니까?

중성자 플랫폼에서 일하면서 저는 이 질문을 여러 번 자문해야 했습니다. 동전의 반대편에 look뿐만 아니라 플랫폼이 실패하게 만드는 이유는 무엇입니까? 내 최악의 두려움은 이더리움과 EVM의 훨씬 더 성숙하고 자원이 풍부한 생태계에 비해 얼굴에 평평하게 떨어질 수 만 중성자를 구축하는 이 모든 노력을 넣어하는 것입니다. 새로운 플랫폼은 비교적 거대한 현직 플랫폼과 어떻게 경쟁합니까? 이에 대한 느낌을 얻기 위해, 나는 블록 체인과 일반적으로 기술 공간에서 많은 기존 플랫폼을 공부했다. 제가 배운 가장 분명한 것 중 하나는 기술적 이점이 플랫폼이 성공, 어려운 진실이 될 것이라고 보장하지 않는다는 것입니다. 이미 EVM보다 기술적으로 유능한 스마트 계약 플랫폼이 많이 있습니다. 그러나, 아무도 심지어 다른 비 이더리움 프로젝트에서 교체가까이 얻을 수 없었다, 훨씬 적은 이더리움 자체. 하지만 더 많은 생각과 공부와 함께, 나는 단순히 말하는 것 이상으로이 질문에 대답하는 방법에 대한 적어도 아이디어가 있다고 생각 "잘 그것은 따라 달라집니다".

각 질문 뒤에 는 많은 미묘한 이유가 있지만, 난 그냥 여기에 넓은 스트로크를 커버하고 싶습니다. 저도 무시한 많은 측면이 있을 것입니다. 이것은 블로그이며 결국 연구 논문이 아닙니다.

개발 플랫폼의 성공을 위한 데 도움이 되는 것

1. 첫 번째 무버 어드밴티지

이것이 가장 큰 이유이며 중성자와 함께 해결할 수 없는 이유입니다. 첫 번째 무버 이점은 실제로 문제를 직접 해결하고 처리하는 첫 번째 것을 의미합니다. 블록 체인 공간의 경우이 경우 이 경우 첫 번째 무버가 이더리움과 EVM이 될 것입니다. 하지만 블록체인 을 벗어난 자바스크립트는 이것의 유명한 예입니다. 자바 스크립트는 플러그인없이 브라우저에서 지원 되는 최초의 실제 프로그래밍 언어. 언어에 대한 개발자의 감정을 보면, 그것은 종종 최고의 오해와 최악의 완전히 증오 ... 그러나 웹 페이지에서 가장 인기있는 언어가 계속됩니다. 그것을 대체 할 수있는 수평선에 있는 유일한 것은, 그리고 틈새 응용 프로그램에 대해서만, WASM (웹 조립)입니다. 자바스크립트는 여러 면에서 정밀 컴퓨팅과 고성능 컴퓨팅에 대한 끔찍한 언어이기 때문입니다. 정밀도는 자바스크립트만의 이상한 부동점 시스템으로 인해 걸림돌이 되는 경우가 많으며, 고성능 컴퓨팅은 자바스크립트의 해석에 의해 억제되고 언어 설계를 최적화하기 어려운 것입니다.

첫 번째 무버 장점은 성공을 보장하는 것이 아닙니다. 제품의 잘못된 관리 또는 향후 사용 사례를 충당할 수 있는 기능 부족으로 인해 낭비될 수 있습니다. 그러나, 그것은 할인 될 수 없는 주요 장점, 그리고 종종 매우 오래 지속.

2. 대규모 제1당 지지

시장 지원에 당신의 방법을 구입하는 것이 가능하다, 그러나 이것은 종종 매우 비싸다, 매우 광범위한 "제 1 자"생태계를 필요로. 또한 시장이 그것을 받아 들일 것이라는 보장은 없습니다. 이 것을 사용하는 성공의 유명한 예는 .NET 생태계입니다. .NET은 자바가 매우 인기가 있었던 시기에 자바의 경쟁자로 처음 나타났습니다. 분명히 .NET은 살아남았지만, "일류" 개발 환경이 되기 전에 10년 이상 Microsoft의 자금 조달과 내부 지원이 얼마나 되는지 알고 있으며 Microsoft 생태계(즉, Windows) 외부에서 노출이 상당히 제한되어 있습니다. 마이크로 소프트는 심지어 .NET 네이티브 C ++ 및 COM API에 2 클래스가 될 보았다 윈도우 RT debacle와이 장점을 낭비가까이왔다, 그러나 그들은 매우 신속하게 그 입장을 반전.

프로그래밍 언어 Go는 적어도 부분적으로 감사하는 이점이 있습니다. 강력한 생태계 지원을 받고 있음에도 불구하고 Go가 실제로 공공 커뮤니티 사고 방식을 가지고 개발되지 않고 Google자체 개발 프로세스에 의해 주도된다는 불만이 많습니다. 그럼에도 불구하고 Go는 개발 플랫폼으로서 압도적으로 성공을 거두었습니다.

3. 커뮤니티 퍼스트

프로그래밍 언어 Rust는 이러한 측면의 예입니다. 모질라가 주로 개발되었음에도 불구하고, Rust의 초기 몇 가지 버전 이후에 훨씬 더 많은 커뮤니티 중심의 개발 프로세스가 있었습니다. 이것은 지속적으로 개발 팀에 다시 공급하고 디자인 토론을 몰고 매우 열정적 인 얼리 어답터 커뮤니티를 보았다. 그 결과 Rust는 마법의 1.0 이정표에 도달하면 이미 자체 패러다임과 개발 패턴이있는 성숙한 언어였습니다. 사람들이 문제가 있을 때 검색할 수 있는 충분한 토론이 인터넷에 있었고, 전반적으로 이것은 아직 성숙하지 않더라도 성공적인 플랫폼으로 이어졌습니다.

4. 부족한 틈새 시장을 다룹니다.

프로그래밍 언어 Rust뿐만 아니라이의 또 다른 예입니다. Rust는 이전에만 C와 C++로 만 채워진 틈새 시장을 덮습니다. 특히, 낮은 오버 헤드를 작성하고 기계에 가까운 쓰기, 고성능 코드. C와 C++는 내부에서 안전하고 올바른 코드를 작성하기 어려운 악명 높은 성가신 언어입니다. Rust는 이전의 틈새 시장을 취하고 정확성과 안전 측면을 강력하게 향상시키는 디자인을 통합했습니다.

이 것의 또 다른 예는 자바, 적어도 초기에. 90 년대에 크로스 플랫폼 코드를 작성하는 부담은 매우 높았다. 사용할 수 있는 추상화 레이어, 더 많은 네이티브 코드 및 기타 문제가 있었습니다. 즉, Windows 98과 Windows 2000을 모두 지원하기 위해 새로운 플랫폼을 지원한다는 의미로, 많은 사용자 지정 코드를 작성하고 지원되는 각 플랫폼에 대한 프로그램을 작성하는 데 필요한 직원이 필요합니다. 이것은 분명히 매우 비쌌고, 그래서 Java를 사용하여 프로그램을 작성하는 것이 훨씬 더 이상적 인 것 같았다. 한 번 쓰고, 각 플랫폼의 차이점에 대한 걱정 없이 어디서나 실행하십시오.

5. 현직 플랫폼과의 "드롭 인" 호환성

이것은 기본적으로 다른 플랫폼, 일반적으로 현직 및 잘 설립 된 플랫폼의 상단에 실행 될 수있는 플랫폼입니다. 이 것의 예로는 형식 스크립트가 자바 스크립트로 변환되는 것과 같은 예입니다. 이것은 솔직히 단지 사소한 이점하지만. 그것은 결코 성공을 보장하지 않습니다. 가장 큰 이득은 기존 툴링 및 라이브러리의 광범위한 생태계를 즉시 상속할 수 있다는 것입니다. 그러나 어떤 면에서는 "구현 세부 사항"만 있습니다. 드롭인 호환 플랫폼을 사용하면 플랫폼은 기존 플랫폼보다 더 혁신적인 작업을 수행할 수 없습니다.

오히려 현직 플랫폼이 새로운 플랫폼과 호환 "드롭 인"이 또 다른 형태가있다. 이것은 상황이 내 의견으로는 더 흥미로해지만 기술적으로 훨씬 더 어려워지는 곳입니다. 이것의 좋은 예는 안드로이드 생태계입니다. 모르는 사람들을 위해, 안드로이드는 기본적으로 매우 전문적이고 새로운 플랫폼입니다. 자바 바이트 코드를 직접 처리하는 대신 자바 코드를 달빅이라는 자체 VM에 컴파일하여 Java와 호환됩니다. 이를 통해 안드로이드는 더 강력한 코드 최적화 등의 형태로 혁신을 추진할 수 있지만, 때때로 누출되는 이 플랫폼 불일치의 대가를 치르게 됩니다. 이 것의 가장 명백한 예는 안드로이드는 "표준"자바 API의 일부가 부족하다는 것입니다, 몇 자바 언어 기능 (특히 동적 코드 주변) 쉽게 안드로이드 내에서 사용할 수 없습니다, 가능성이 더 많은 미묘한 세부 사항. 에 관계없이, 그것은 여전히 안드로이드 플랫폼은 개발자가 플랫폼을 사용하기 위해 훨씬 작은 학습 곡선을 가지고 있다는 점에서 큰 이점을 가지고 있다는 것을 의미, 기존의 코드의 많은 노력의 최소한의 방법으로 안드로이드에 이식 할 수 있습니다.

이제 동전의 반대편을 살펴보겠습니다. 개발 플랫폼을 실패하게 만드는 데 무엇이 도움이 될 수 있습니까?

1. 근본적인 보안 문제

브라우저 내에서 플래시와 자바 모두의 죽음은 적어도 부분적으로 비난하는이 문제가있다. 플래시의 경우 Adobe(및 이전에 매크로미디어)가 더 잘못 관리했지만 Java의 경우 훨씬 더 근본적인 디자인 결함이 있습니다. 같은 문제는 Silverlight (.NET 애플릿에서 마이크로 소프트의 시도)로 확장됩니다. 2000년대 후반과 2010년대 초반에 실현된 한 가지는 브라우저가 근본적으로 적대적인 환경이며, 브라우저가 작성된 코드는 이러한 적대감을 면밀히 보호하기 위해 작성되어야 한다는 것입니다. 플랫폼이 "X 백만 명이 컴퓨터 바이러스를 얻는 것으로 이어질"라는 뉴스에 있을 때, 소비자는 회의론으로 그것에 대해 구축 된 모든 제품을 보기 시작합니다. 이렇게 하면 개발자가 플랫폼에 너무 많이 의존하지 못하게 됩니다.

2. 높은 입장료

.NET을 가진 Microsoft의 초기 실패 중 일부는 2000 년대의 .NET이 상당히 높은 진입 비용을 가지고 있다는 것입니다. 사용자가 실제로 .NET 프로그램을 사용하는 데 드는 비용은 아무것도 하지 않았지만 .NET 프로그램을 작성하려면 거의 항상 Visual Studio가 필요했습니다. 오늘은 전체 비주얼 스튜디오의 "커뮤니티 에디션"이 있으며 물론 .NET 코드는 무료 및 오픈 소스 편집기 인 VSCode를 사용하여 쉽게 작성 할 수 있습니다. 그러나, 그 때 그것은 비용 $500+ 비주얼 스튜디오의 라이센스에 대 한. 이로 인해 소규모 프로그래머가 생태계 내에서 발전하는 것을 직접 낙담시켰고, 전반적으로 생태계의 "오염"을 초래하여 소규모 개발자와 신생 기업이 생태계에 가입하는 것을 더욱 낙담시켰습니다. 비슷한 죽음은 델파이 프로그래밍 언어의 몰락이었다. 내가 아는 한 그들은 결코 무료 컴파일러를 판매하지 않았기 때문에 더 강력한 무료 프로그래밍 언어가 튀어 나오면서 경쟁 할 수 없었습니다. 그것은 "레거시"플랫폼으로 붙어있는 것 같다, 오히려 위에 새로운 것을 구축하는 이상적인 플랫폼보다. 들어오는 개발 생태계와 지역 사회의 부족은 시간이 지남에 따라 궁극적으로 악화됩니다.

이것의 더 많은 역사적 예뿐만 아니라 현대 시대로 지속되지 않았다 매우 비싼 개발 플랫폼. 이것의 명백한 예는 리눅스입니다. 리눅스가 처음 출시되었을 때, 오픈 소스는 다소 새로운 개념이었고 당시의 유닉스 시스템은 매우 비싸며, 지원이나 버그 수정의 특별한 보장없이 특정 기계에 대해 조정 된 단일 "복사"에 대한 오늘날의 돈의 거의 $ 100K 가치가 있었습니다.

3. 매우 구체적인 사용 사례 및 환경에 대한 가정

매우 구체적인 사용 사례 또는 매우 특정한 환경에서만 사용된다고 가정하는 언어 및 개발 플랫폼은 이러한 잠재적 인 몰락의 영향을 받습니다. 그것은 때때로 단지 "문제" 오히려 몰락의 원인 보다, 하지만이 기술 생태계를 통해 이동 하는이 많이 있다. 다운폴의 좋은 예는 ActionScript의 실패입니다. 이것은 플래시 애니메이션과 게임에 사용되는 프로그래밍 언어였습니다. 그것은 잘 설계되고 사용하기 쉬운 언어로 매우 널리 칭찬하고있다, 아직 2021 년으로 그것은 효과적으로 죽었다. 단점은 플래시 애니메이션 (내가 볼 수있는 한)에 거의 독점적으로 사용되었으며 해당 사용 사례를 중심으로 특별히 설계되었다는 것입니다. 플래시가 죽었기 때문에 이제 액션스크립트도 실질적으로 있습니다. 어도비는 AIR 플랫폼을 사용하여 살아 남기 위해 노력했지만 궁극적으로 그 플랫폼은 실제로 이륙하지 않았고 플랫폼에 소비자를 노출 시킨 인기있는 제품 중 하나만 보았습니다 (TweetDeck)

이 측면의 또 다른 덜 틈새 예는 실제로 자바 스크립트입니다. 오늘날에도 인기 있는 플랫폼임에도 불구하고 NodeJS를 통해 서버 측 공간으로 이동할 때 상당한 통증이 커졌습니다. Javascript의 핵심 디자인은 노골적으로 확장 할 수없는 여러 가지를 가정하고, 이러한 디자인 문제를 해결하는 것은 고성능 응용 프로그램에서의 사용에 상당한 양의 복잡성을 도입하는 경향이있다.

중성자는 어디에 서 있습니까?

그렇다면 이 기사의 목적인 중성자의 포지셔닝은 어디에 있을까요? 우리는 이러한 범주 중성자 중에서 속하는 분석할 필요가 있습니다.

• 우리는 물론 이더리움에 첫 번째 무버 이점을 놓쳤다. 이것에 대해 아무것도 할 수 없습니다.
• 우리는 우리가 "강제 입양"에 의존 할 수있는 거대한 제 일자 (즉, Qtum / 얼 그레이 테크)가 없습니다. 우리는 많은 자원을 가지고 있지만, 우리는 필요한 시간의 연장 된 기간 동안 이 가능하게 할 수있는 Fortune 500 수준의 자원이 없습니다.
• 커뮤니티 첫 번째 접근 방식을 취하는 것은 어렵지만, 우리는 그것을 시도할 것입니다. 우리는 곧 중성자 설계에 기여하고 초기 생태계를 형성하는 데 도움이되는 필요한 정보를 가진 파트너에 대한 호출을 발표 할 것입니다. 우리는 중성자가 Qtum을 넘어 블록 체인과 플랫폼에 채택된 경우에만 성공할 수 있다고 믿습니다. 그러나 개발을 완전히 열어 두는 것은 우리가 여전히 배우고 있는 것이기 때문에 여기에 걸림돌이 있을 것입니다. 어쨌든, 우리는 근본적으로 우리의 개발 프로세스를 열고 찾고 있습니다. 여기에는 현재 프로젝트 관리 시스템(Trello)을 공개적으로 볼 수 있게 하고, 누구나 함께 참여하고 들을 수 있도록 개발 회의를 개최하고, 성적증명서와 모임 노트를 커뮤니티에 제공하고, 커뮤니티에 직접 질문과 우려를 제기하기 위해 예정된 커뮤니티 통화를 하는 것이 포함될 수 있습니다. 우리는 이 중 일부를 시도할 것이고, 다른 여러 가지를 시도할 것이지만, 이 새로운 과정을 탐색할 때 약간의 시간과 고통이 필요할 것입니다.
• 중성자는 부족한 틈새 시장을 제공하도록 설계되었습니다. 특히 블록체인과 레이어 2 모델은 단순히 이더리움의 설계 방식과 "메쉬"하지 않으므로 EVM을 통합하는 것은 블록 체인의 기본 모델과 조정하기 어렵거나 플랫폼의 기능을 노출하는 데 큰 복잡성이 필요합니다. 중성자는 "이더리움 기반이 아닌 모든 것을 위한 스마트 계약 플랫폼"으로 설계되었습니다. 이런 식으로 우리는 자신의 잔디에 이더리움에 대한 "경쟁"을 피하기 위해, 오히려 우리는 이더리움 기술이 작동하지 않거나 작은 의미가없는 장소에 중성자를 넣어 싶어.
• 중성자는 중성자 스마트 계약을 작성하고 즉시 이더리움에서 실행할 수 없다는 측면에서 EVM과 호환되지 않습니다. 그러나 그 반대의 경우도 마찬가지입니다. 특히, 이더리움 스마트 계약을 작성하고, 표준 견고성 등 툴링으로 컴파일한 다음 중성자-EVM을 통해 중성자 플랫폼에서 직접 실행합니다. 이것의 정확한 디자인은 EVM이 쉽게 표현할 수 있는 것에 비해 중성자가 노출할 수 있는 기능이 얼마나 많기 때문에 여전히 공중에 아주 멀리 떨어져 있지만, 이것은 중성자의 핵심이 확립된 후에 더 강하게 바라기 시작할 측면입니다.
• 중성자는 저렴한 입장료로 설계되고 있습니다. 특히, 우리는 블록 체인 및 L2 제공 업체가 통합 할 수있는 플랫폼을 가능한 한 간단하게 하는 것을 목표로하고 있습니다. 여기에는 분산형 소프트 포크 및 하드 포크 옵션, 반중앙화 노포크 방법을 처리하는 확장성이 포함됩니다. 이러한 정확한 메서드는 나중에 완전히 설명됩니다.
• 중성자는 스마트 계약 플랫폼을 위해 가능한 한 적은 가정을 합니다. 블록 체인 / L2 플랫폼에서 모든 중성자 요구는 매우 최소한의 핵심에서 스마트 계약 바이트 코드를로드하는 방법입니다. 그러나 이러한 플랫폼에서 사용할 수 있는 다양한 기능을 논리적이고 일관된 방식으로 커버할 수 있을 만큼 광범위하게 설계되었으며 건축적 변경 사항은 없습니다.