Alt-chain release RFC

提供: tezos-wiki
移動先: 案内検索

このドキュメントは新しいaltチェーンを発行するための提案されたプロトコル(RFC)です。 公式の "RFC言語"に必ずしも従うとは限りません。あなたがそのような問題について賢明であれば、それを編集して、 "どのようにRFCがどのように見えるべきか"という公式の形式に合うように編集してください。

もちろん、プロトコルへの遵守は必須ではありません。このプロトコルに従うことは、著者が希望する財産として保有しているコイン配布において公正さを達成するための良い方法の1つであるという著者の考えです。以下の時定数は任意に選択され、必要に応じて調整することができます。

なぜ競争するのですか?[編集]

Bitcoinは既に採用を拡大するためのハードルを持っています。 競合する暗号化通貨を導入することによって、何の理由もなくより多くを創り出すことは、賢明ではありません。 したがって、新しい暗号化通貨を作成することを選択した場合は、事前に強力な理由を固め、貴重な情報を提供できる暗号通貨での作業経験がある他の人と話し合うことをお勧めします。 通常、自分自身に尋ねる最初のことは、競合する代わりにBitcoinを改善してみませんか? あなたの変更に「ハードフォーク」が必要な場合や、既存のBitcoinコミュニティから肯定的な回答がすぐには得られない場合でも、互換性のない(おそらくは互換性のない)テストネットワークでそれらを試すことができます「TinyCoin」の代わりに「Bitcoin Infinite Division Test」など)を実際の通貨として交換/使用しようとしません。 適切な開発努力をしてBitcoinが採用できないものはほとんどありません。 たとえば、NamecoinBitMessageは非通貨目的でBitcoinテクノロジを使用しますが、 PPCoinとFreicoinは、Bitcoinが採用されている経済社会契約に違反する変更を導入しています(Bitcoinに対する1つ以上の[禁止の変更]に違反しています)。

基本的な変更[編集]

Bitcoinには、[Hardfork Wishlist | "ハードフォーク"]がなければ修正できないいくつかの欠陥があります。 深刻なaltチェーンは、少なくともこれらの懸念や問題に取り組むべきです。

アナウンス形式[編集]

altチェーンの最初のアナウンスには、少なくとも1つの主要な公共の道が含まれなくてはなりません(MUST)。 現時点では、[[RFC] <Alt-Chain-Name> - <tl; dr>というタイトルのBitcoinTalkのalt-chainサブフォーラムへの投稿を含めるべきである[SHOULD

[tl; dr]はaltチェーンの短い1行の説明です(例: "[RFC] - MinorLeftieCoin - 左下の18歳以下のaltチェーン!"

RFCスレッドには、コインのタイムラインが含まれていなければならない(SHOULD)(下記参照)。

この時点で別のプレースホルダ 'アナウンススレッド' を作成することもできます(例: "[ANN] MinorLeftieCoin")。このaltチェインについてのすべての "アナウンスメント はそのスレッドに入れなければなりません。このスレッドは、アナウンスメントだけを購読したい人には役に立ちます。 Twitter / Blog / Google +などの他のアナウンスチャネルも公開することができます。

起動タイムライン[編集]

RFCスレッド[編集]

これは最初のステップであり、ネットaltチェーンの重要な要素を明確かつ簡潔に提示する必要があります。この投稿には以下が含まれています:

'Who' - チェーンの背後にある開発者/創設者(フォーラムID +実際の名前、連絡先情報、以前のプロジェクト、twitter IDを含む可能性のある他の情報) # 'Benefits' - Bitcoinの主な利点 - なぜこのチェーンがBitcoinの主なチェーンと競合すると思いますか? # '他のalts' - 該当する場合、他の重要な暗号化通貨との比較。 # 'Merged mining' - これはMerged Miningをサポートしますか?既存のチェーンはどのくらい正確に実装されますか?マージされたマイニングはいつ有効になりますか? # 短所 ' - このAltチェーンで何が問題になるのでしょうか?欠点は何ですか? # 'オープンソースライセンス' - すべてのaltチェーンノードソフトウェアは、完全なオープンソースでなければなりません。彼らは[1]であるべきである(SHOULD)。正確なライセンスは、起動する前に選択する必要があります。 # 'スケジュール'

    1. 提案されたソースコードの公開日 - これは、RFCの後にいつでも発生する可能性があります。著者はソースコードを入手できるようになるとすぐにリリースすることが奨励されていますが、望むのであれば「コードベースの適切な成熟度」を待つことができます。
    2. Pre-Launch(testnet)Date - これは、ソースコードの公開から1週間後、RFCスレッドの少なくとも2週間後に行われ、適切な議論とレビューの時間を確保する必要があります。
    3. 提案された発射日 - これは、試験のために、発射前の日付の少なくとも2週間後でなければならない。
    4. 開設予定日。これは、開始日または終了日のいずれかで行うことができますが、事前に通知する必要があります。

作者がプロセスを早くしたい場合、上記のコンポーネント(例:ローンチスケジュール、特定の技術的詳細)は、最初のRFCからスキップできます。しかし、これらの日付は、アナウンススレッドにメッセージをポストし、RFCスレッドのトップポストを更新することによって、RFCスレッドが「クローズ」される前に埋められなければならない(MUST)。

ソースコードのリリース[編集]

これは、RFCの公表と発売前の1週間前の 'までの間にいつでも従うことができる'必須のステップ 'です。起こりうるバグ/バックドア/問題のソースコードを調べるために1週間の期間が必要です。


プレリリース[編集]

このステップは、RFCで予定されている日付より早く行われてはならず、ソースコードを公開してから少なくとも1週間はかかる必要があります。著者がもっと時間を必要とするならば、それは様々な理由で遅れることがあります。

プレラウンチの目的はaltチェーンのドライランを行うことです。このドライランは専用のテストネット上で行わなければなりません。

リリース前のフェーズには、少なくともLINUXとWINDOWSバイナリを含む公式のバイナリリリースが伴わなければならない(MUST)。バイナリは、デーモンとGUIの両方を含むべきです(SHOULD)。

プレリリース前のフェーズには、バイナリの公開用の正式なチャンネル(例えば、Github、SourceForge)が含まれなくてはなりません(Mith)。

ソフトウェアのバージョンを適切に変更する必要があります。リリース前のバージョン番号には、0.1,0.2,0.3、... 0.8,0.9,0.10,0.11、...(マイナーなバグ修正のリリースでは0.X.1、0.X.2、...)の番号が付けられています。 。 1.0以降のバージョンは、ソフトウェアが安定するまで使用してはいけません。

4.起動する[編集]

このステップは、RFCで予定されている日付よりも早く行われてはならず、実行前の少なくとも2週間後に実行する必要があります。これは、テストネットリリース(テストネットはいつでもリセットできます)であったリリース前のリリースとは対照的に、価値のある公式のチェーンです。

起動前フェーズの同じバージョン管理とバイナリリリースのガイドラインが、起動フェーズに適用されます。


さらなる注釈[編集]

#クライアントへのメジャーアップデートは、LinuxやWindowsを含むすべてのサポートされているプラ​​ットフォームでリリースされていなければなりません。これは自動化または半自動化できるので、「Windowsでコンパイルする方法がわからない」という言い訳ではありません。Windowsでコンパイルする方法を知っている人を信頼してください。リリースはすべてのプラットフォームで同時にリリースされるべきである(SHOULD)。