關於EOS.IO公約的講解
版權宣告:
以下內容來自微信公共帳號“EOS技術愛好者”,搜尋“EOSTechLover”即可訂閱,作者Thomas Cox,整理者Yvonne。轉載必須保留以上宣告。僅授權原文轉載。
寫在前面:此文可以看作是關於Thomas Cox對公約的制定及思考過程,我們將它集合在一起方便大家閱讀。本文不詳細羅列現存公約的條例(https://github.com/EOS-Mainnet/governance/blob/master/eosio.system/eosio.system-clause-constitution-rc.md ),相信你在讀完此篇之後會有更深刻的理解。我們做了中文翻譯(https://steemit.com/eos/@eoshenzhen/bp-eos), 翻譯時的屬於純直譯,在表述上應該會存在很多大家不認同的地方,但相信結合此篇你會有自己更深刻的理解。
正如托馬斯所言,EOS.IO公約所針對的情景僅限於on-chain,以及對此文所提到的關於仲裁、英美法系、李嘉圖協議、衡平法等專有名詞,包括對EOS理解,都可以參照https://steemit.com/@eoshenzhen 之下的文章。特別是Ian Grigg所寫的《EOS簡介》 https://steemit.com/eos/@eoshenzhen/4ackmh-lan-grigg-eos ,會幫助你更好的理解EOS。
讓我們開始吧!
———EOShenzhen
一、設計EOS.IO公約草案0.1版本的原則
標準、目標和原則,通過以下6點可以看到起草過程中為什麼選擇這樣的設計。
1、消極權利
對甲方而言,“消極權利”是指其他人不採取具體行動,如不進行人身攻擊。消極權利能夠同時保護持有人的權利,並保證其他人的最大行動自由。這也更容易讓消極權利更加相輔相成。
2、簡介
目的是寫一份簡明扼要的檔案,闡明核心原則,詳細細節和使用案例可由社群在公約之外再製定。以上可採用智慧合同語言、李嘉圖合同語言、飛地協議、仲裁裁決等形式。
3、僅限英語
有人擔心,因為語言語義上不可避免地會有細微差別與誤解,所以用兩種或兩種以上語言進行翻譯的公約會造成混亂或不必要的誤解。
避免這種情況發生的唯一方法就是在一種語言中使用一個參考附件。考慮到本專案的發展歷史,以及制定者對英語以外其他語言認識的不足,選擇了英語作為此公約的唯一語言。
4、巢狀級別
社群經常討論不可避免的和高度可取的是“飛地”的情況,也就是部分成員相互達成權力共識和在內部形成相當的規則,形成了小型社群——一個更大空間的子集或部分,其中的人和規則與周圍的環境截然不同。
基於主網的EOS.IO軟體將是第一個級別。在它的內部,可能會有一個(比方說)飛地是關於遊戲的,那裡有一系列特殊的遊戲應用程式,人們可以選擇進入遊戲區。除了可以訪問特殊的Dapps之外,同時也將會受到其中的約束。在遊戲這個飛地中可能會巢狀一個遊戲大師的小飛地,甚至有更特別的規則,這也許會是一人一票的規則。爭端總是在爭端當事人涉及在內的最小飛地範圍內解決,並根據該飛地的規則,繼承從屬飛地的任何規則。
5、生命、自由和財產
EOS.IO軟體的主要領域是財產。意思是,人們不是生活在區塊鏈,也不能被一個人逮捕或監禁(儘管可能基於這個人在區塊鏈上的行為會被一個政府逮捕和監禁)。它一直是EOS.IO專案的設計目標,用其他系統不能的方式保護人類的生命、自由和財產,建立一個為應用程式提供DApps和支援的生態系統。憲法將致力於支援這一使命。
6、與社會規範協同
Lawrence Lessig在《新芝加哥學派》的文章中(在《法律研究雜誌》(1998年6月)第27卷第2期中發表)提到,在一個系統內有四種力量影響著人類行為:法律、社會規範、市場和體系結構(即技術基礎設施或程式碼)。公約的目的是榮譽地並和創造一個供四種力量能都按理想方式執行空間的方式來制定公約。
二、憲法草案背後的思考
(一)第一條——不說謊
目的
在這個區塊鏈上的使用者不得做虛假或誤導性的陳述,也不得因此從中獲利。
說明
“這條鏈上的使用者” 應該被理解為每一個token持有者、每個帳戶持有人以及每一個通過DApp使用區塊鏈的人。這包括一個可以與DApp進行互動的人,DApp會保留這個人使用的所有token,而這個人沒有獨立的或分開的token和帳戶。這似乎需要通過“死人測試”("dead man test")來獲得消極權利——死人滿足禁令要求,不會出現 “故意編造虛假的或誤導性的陳述”。這裡有兩個禁令,一個是反對編造陳述(making statements),另一個是反對獲利。這可能是重複或誇大;前面的內容可能會暗示 “也不得因此獲利” 這句話。“不獲利” 這句話是為了增加透明度,並指出如果A因為C的錯誤陳述而損失了金錢或財產在B上,那麼A可以在B和C上重新取回其損失。
(二)第二條——財產權
目的
在區塊鏈上,合同是財產權交換的主要方式。財產權是所有現代民主制度的基石,尤其是區塊鏈的核心價值。
說明
此第2條包含以下幾點:
如果你以不正當的方式獲得任何財產,比如有人賣給你一輛偷來的自行車,而他們(小偷)從來沒有合法擁有過,也就是沒有過正當的所有權,那麼你購買那輛自行車的行為是無效的。當自行車真正的所有者出現時,財產法要求你將自行車物歸原主,而你可以試著從小偷那裡追回你的錢。
除非賣家能證明他們用有所有權,否則你不應該買東西。
當你買東西的時候,你應該注意哪些背景不明朗的賣家,比如沒有明確的身份、沒有保險、沒有行業協會來保證其成員的可信度、沒有出示過履約保證書。( “履約保證金” 指的是賣主擁有但不能迅速收回的一筆錢,因此,如果你在和那個賣主的判決中勝訴,這筆錢就可以支付給你了。)
在每一份智慧合同和每一筆交易中都有李嘉圖合約的存在,這對確立雙方的意圖有很大的幫助。一個典型的自行車銷售交易可能包括一些條款,比如 “我作為賣方,保證這輛自行車全部的和正當的所有權都歸屬於我。”當這個陳述被證明是錯誤的,你就有了一個非常強有力的證據來反對賣方欺詐。
另一方面,如果其中一個條款顯示 “我作為買方,擁有充足的機會檢查這輛自行車的所有權,我對它怎麼來的沒有任何異議,並對賣方有不損害他方糾紛事件的所有權持同意態度。” 如果之後它被證明是偷來的,截然不同的結果也會隨之而來。你將會失去這輛自行車,並在向賣方索賠時面臨嚴重的困難。(自行車被偷的主人仍然可以對小偷提出索賠,如果賣家被騙了,賣家也可以這麼做。)
(三)第三條——仲裁
目的
正如之前的設計原則草案所設計,EOS.IO軟體將提供一個“治理區塊鏈”,通過有約束力的仲裁解決糾紛。此條的目的僅僅是建立和授權具有約束力的仲裁的存在。
主題
所有的成員同意通過區塊鏈預設的仲裁程式,或任何其他交易雙方可能都同意的程式解決爭端。
討論
合同是在區塊鏈上交換產權的主要方式。由於我們不能指望程式碼是完美的,所以我們需要看例外案例的處理過程。(相信)鏈上和仲裁員之間會有單獨的“仲裁協議”,並且準備啟動或在這不久之後,(相信)至少有一個完整的爭議解決規則仲裁論壇(RDRs)和一個仲裁員小組。(想象)需要系統級合同來跟蹤預設級別的仲裁案例。
當有人向你提出異議時,需要有一種通知當事方的方法,讓你知道發生了這種情況。可以是通過會員負責監控的鏈上廣播來通知,與“ 記錄報紙上的釋出通知”(https://en.wikipedia.org/wiki/Newspaper_of_record#Newspapers_of_public_record )不同。
啟示
意味著幾件事情:在鏈上的糾紛通過鏈上仲裁程式得到處理。在鏈下的糾紛處理就像他們已經在鏈下了一樣(人類一直在為所有有記錄的歷史彼此爭辯,而且肯定超越了)。
如果不確定你的糾紛是在鏈上還是鏈下,請提出你的訴求。為了限制不正經的和“仲裁垃圾郵件”,很大可能會有申請費的設定。濫用該制度本身可能會導致與始作俑者的糾紛,讓這些人不得不支付罰款和/或面臨一些其他後果。
問題與解答
很多人都問過關於鏈上仲裁如何運作的問題:
Q:如果仲裁員與糾紛中的一方暗中勾結,怎麼解決?
A:決定可以上訴仲裁員的理由不多,其中一個是仲裁員不是獨立的。
Q:如果仲裁員錯了怎麼辦?
A:決定可以上訴仲裁員的理由不多,其中一個是仲裁員非常無能。
Q:如果仲裁員做錯了其他事情怎麼辦?
A:仲裁已使用數十年。仲裁員可以在鏈上或者鏈下犯錯誤。如果你對在仲裁中如何處理特定的錯誤還是很好奇,你應該研究仲裁,而不是區塊鏈。
Q:仲裁員進行裁決在區塊鏈上是合法的嗎?
A:是。我們正在盡一切努力確保鏈上仲裁對鏈上和鏈下都具有約束力。幸運的是,自1958年以來,已有150多個國家簽署了承認和執行仲裁員來裁定的協議,其中包括沒有定居在這些國家的仲裁員。我們有充分的理由相信EOS.IO區塊鏈上的鏈上仲裁將以完全相同的方式進行處理,如果發生了鏈上的仲裁案件,應該會在國家法院面前解決糾紛。
Q:仲裁是否需要事先商定?
A:是的,這是最好的做法。在糾紛出現之後,雙方可以同意新的仲裁程式和討論(forum),也可以同意在沒有任何仲裁員的情況下解決爭議。經驗表明,提前指定仲裁法庭(forum)是一個更好的選擇。
進一步的工作
關於糾紛解決規則(RDRs)的預設設定,應該回答了大多數人關於仲裁案例如何展開、決定和執行這些的詳細問題。這在公約中沒有規定。
(四)第四條——不買賣選票
選票代表公共利益。當token持有者真正花時間去了解情況並明智地投票時,整條鏈也將會因此受益。這個話題已經被廣泛討論過了,例如在這裡(https://medium.com/@thomas.cox_39839/whither-the-6-month-vote-lockup-f683d31d8de2 )和這裡(https://forums.eosgo.io/discussion/353/why-paying-for-votes-is-bad )。
(五)第五條——不存在所有者或受託人
EOS.IO軟體建立了一個治理的區塊鏈。它是自治的,並非由任何人或某一群人擁有或控制的,除非成員集體行動。重要的是,EOS token不能變成證券。如果區塊鏈以某種方式獲得受託人,比如,若是token持有人在私下合理地期望某人或某個組織像受託人那樣照顧自己的利益,這可能會導致token會成為某種程度上的證券。為了防止這種情況的發生,我們宣佈該鏈上沒有所有者(全體成員除外)和受託人。
(六)第六條——不超過10%的所有權
EOS.IO軟體不得有受託人。為了防止這種情況,以及防止大戶(whale)對整條鏈的控制,此公約建議任何 “成員或受益人權益” 的所有權不超過所有發行token總量的10%。
本條內容
任何成員或受益人權益均不得超過已發行token的10%。
(七)第七條——處罰協議
目的
法律和協議必須執行和可被執行。此內容指出,如果成員被發現違反了規則,成員同意接受處罰。這避免了通過單方面聲稱不同意遵守規則或承擔違例後果的人出現逃避責任的情況,並且通過集體行為體系評估對彼此的處罰,使社群更加規範化。
本條內容
每一個成員同意對違規行為的處罰,包括但不限於罰款、凍結賬戶和撤銷交易。
討論
這個條款很簡單。它明確地指出了在同一公約的早期條款中所隱含的內容,即其中的規則可以被強制執行,當違反集體規則時,成員面臨且同意接受其中規定的懲罰。懲罰方式由仲裁員通過手頭上的具體案例來決定的。
應該存在一份社群檔案,註明當發生一些有代表性的違規行為後,“標準” 的規定處罰是什麼。這份檔案不應該成為公約的一部分,但很大可能會隨著社群當發展而發展。
(八)第八條——《BP協議》
目的
本文授權了一個治理文件,即《BP協議》。為了讓全體成員共同採取 “要麼接受要麼放棄” 的提議,並設定好社群成員希望每個BP做的事情 (以及避免做的事情) 的界限。
本條內容
若事先未對此區塊鏈成員提供的《BP協議》確認同意,任何人均不得以BP自居。
討論
此憲法草案力求簡明扼要,相比之下《BP協議》也許會盡可能詳細。因此決定將該協議到分類到自己的檔案中去。
如果憲法的組成中沒有這個內容,那麼從治理方面看,《BP協議》充其量是一份 “擁有的話比較好” 而不是 “必須擁有” 的存在。
BP很有可能同意《BP協議》並承諾更多額外的東西,來表明自己的可信度從而吸引選票。對於BP比在《BP協議》中有更高的追求標準,這本該沒錯。
同意的方法沒有正式確定下來。很有可能會像李嘉圖合約中的 “RegProducer” 系統命令,一個成員註冊為BP候選人,其中包含參考資料中的《BP協議》。按照這樣的設定,那作為註冊BP候選人的這個行為,意味著需要先同意《BP協議》的內容。如果真是如此,大家可能會認為該條款是多餘的。但事實並非如此,此條款將《BP協議》的地位從僅僅是一份合同的協議,提升到與公約相當的管理檔案。這使《BP協議》在仲裁案件中有了更高的地位;具體來說,《BP協議》像《公約》一樣有權否決任何合同,如果其間有衝突的話。
(九)第九條——建立仲裁法庭
目的
建立治理的第三個支柱——司法。並限制仲裁員只在仲裁法庭的範圍內行駛權力 (更多關於仲裁法庭的內容,請閱讀討論部分)。
本條內容
任何仲裁員不得在仲裁法庭之外的場合行使仲裁權。
討論
如以下幾點:
仲裁者不是自由放養的獨行俠,而是在非常嚴格的約束下行使權力的:
1、他們只對由一方提出的案件進行裁決。
2、他們在認證了仲裁法庭之內的規則後,執行仲裁。
3、他們的工作受所屬法庭的監管。
4、他們公佈了調查結果和公眾意見的列表 (在案件的當事人可能會因公佈內容受到傷害,其中部分內容可能需要保密的情況除外)。
5、他們的仲裁裁決必須反映公約、案件中具體引用的合同,以及新興的社群規範。
6、仲裁法庭是以下內容的整合物:
一套用於管理仲裁案件和裁決這些案件的、特定的糾紛解決規則(RDR)。
一組特定的,組織此法庭、案件管理和分配仲裁員的人。
一個培訓仲裁和認證制度的系統。
一組經過培訓和認證的獨立仲裁員。
一個特定的仲裁法庭是如何被授權審理案件的?在糾紛者雙方爭端出現之前或之後(最好事先同意),均同意使用這個指定的法庭。
糾紛者雙方已經簽署了一份規定了該法庭使用的合同。
糾紛者雙方是社群或飛地(enclave)的一部分,作為其中一員他們同意使用此法庭。
考慮到特殊情況,EOSIO憲法應該指定一個特定的論壇,以防之前的條件沒有都得到滿足的情況下,仍然有一個預設的論壇作為備用。
“forum”這個詞的複數形式是“fora”,我選擇了“forums”,因為這已經是英語的習慣用法了。
(十)第十條——仲裁員標準
目的
設定仲裁員和仲裁法庭的最低標準。
本條內容
若未達以下條件,任何成員均不得以仲裁員自居:
事先同意由會員提供的仲裁協議;
至少由兩名其他成員提名;
完成了仲裁法庭的學習以及獲得認證,並在其中有良好的口碑。
討論
沒有——在此公約中關於仲裁的大部分討論可見第九條。
(十一)第十一條——開發人員和智慧合約許可證
目的
定義什麼程度的成員才是開發人員。設定開發人員有義務提供許可證、李嘉圖合約(一個或多個),併為他們的開發軟體任命一個仲裁法庭。
本條內容
每一個在區塊鏈上提供智慧合約的成員都應該是開發人員。每一個開發人員都應通過許可證來提供他們的智慧合約,每一份智慧合約都應記錄在一份說明各方的意圖的李嘉圖合約中,並指定解決該合約糾紛的仲裁法庭。
討論
在程式碼釋出但沒有提供許可證或李嘉圖合約的情況下,從憲法層面上不清楚發生什麼,或應該發生什麼。EOS.IO軟體在程式碼級別方面也是一樣。仲裁員則被要求找出如何處理這種情況。要是正在考慮執行某軟體,應該警惕沒有明確許可證和沒有任何李嘉圖合約的軟體。許可條款當然有可能被李嘉圖合約引用,甚至完全包含其中。這可能是個很好的實驗。
(十二)第十二條——多語種合同
目的
為了避免官方指定版本的合約出現歧義,需要提供多種語言版本的合約。
本條內容
有糾紛的情況下,多語種的合約必須指定其中一種作為優先語言。
討論
正如之前所討論的那樣,此公約的官方語言是英語。它可能會被翻譯成其他語言,但在糾紛中優先採用的版本是英語。
同樣的,一份提供多語種的合約需要提前宣告遇紛時優先選擇的語種。
要是作者沒有指定優先語言,它將由糾紛的仲裁者來決定(除非糾紛者都同意某一個語種)。在這個討論部分中沒有辦法預測或控制這樣的決定將如何展開。因此,對於每個開發者來說,最好是要麼只提供一種語言,要麼明確表示官方語言和通用語言。
(十三)第十三條——開發人員對非成員的訪問負責
目的
確保鏈上所有的互動都有人負責。
本條內容
由於開發人員能夠通過應用程式向非成員提供服務和與區塊鏈的互動,所以開發人員需要保證非成員此公約範圍之內進行互動,並承擔其中可能發生的所有責任。
討論
很容易想象,去中心化應用程式的開發人員很有可能會允許一個不是成員的人(即沒有任何token且沒有簽署公約的人員)在鏈上活動。例如,他們可以提供匿名交易,或維護鏈下的使用者列表,允許使用者在鏈上通過開發人員自己質押的token得到CPU、頻寬和RAM的空間來執行操作,並在開發人員許可權設定下使用。
作為非成員和潛在匿名者的外部使用者,將很難對鏈上可能引發的任何後果負責。
因此,開發人員必須承擔此類責任。
(十四)第十四條——無積極權利
目的
防止建立公約的積極權利。
本條內容
此公約不為任何成員(或任何成員之間)創造任何積極權利。
討論
正如公約草案的設計原則(https://forums.eosgo.io/discussion/424/design-principles-of-my-v0-1-draft-eos-io-constitution )中所述的那樣,公約不會直接或間接地創造任何的積極權利,其中幾個重要原因如下:
消極權利為各方提供了最大的行動自由;
就算不作為,消極權利(幾乎)總是可以得到尊重,而同樣前提下的違規行為(通常)卻很容易被發現;
消極權利不會使他人承擔義務,不會權利發生滑坡謬誤,也不會使鏈上的預設token真正變成證券;
(圖:譯者注)
目的是要明確其他任何條款,以及其下一級從屬的治理檔案(BP協議、仲裁協議等)中,都不能或不應該被解釋為可以賦予任何成員積極權利。
(十五)第十五條——指定預設仲裁法庭
目的
明確指定處理糾紛的預設仲裁法庭。
本條內容
此公約及其相關治理檔案引起的一切糾紛,均將使用 “EOS核心仲裁法庭” 解決。
討論
每一份合約都需要指定預設仲裁法庭。由於此公約是一份合約,所以也必須指定它預設的仲裁法庭。
只有到具體合約產生糾紛,此時沒有指定另外的法庭,或他們與此公約指定同一法庭時,產生的合同糾紛將會進入到之前預設的法庭執行仲裁。
“EOS核心仲裁法庭”(撰寫本條時)作為一個獨立的實體被建立起來,旨在為EOS區塊鏈提供解決糾紛的服務。
(十六)第十六條——修訂案
目的
建立修訂治理檔案和系統的規則。
本條內容
根據當前系統合約的條款,本憲法及其所從屬檔案中的《BP協議》和《仲裁協議》不得修訂,除非token持有者參與投票的token數量不少於符合條件token總量中的10%,且贊成票要比否定票多10%,並且以上條件要在120天的時間段內持續30天,才可生效。
討論
“投票權”一詞表明,根據系統軟體處理,一個人的投票票數是根據其為CPU和頻寬所質押的token數量來計算的。
這裡所描述的投票可以是,但並不一定是要通過系統級別的合約進行的,它必須在鏈上處理。
“根據當前系統合同的條款”這個內容,在此時的軟體規範中涵蓋了以下的預期(可參見GitHub #2226):
任何人都可以提出新的系統合約;
需要存入1,000個EOStoken。當修訂案通過後,可以拿回其中的90%。
提案是一個新系統合約,並且是一個加上安裝Proposed Tx的二進位制檔案;提交者來驗證和(或)向選民證明二進位制程式碼是有效的原始碼;為了方便其他人可以驗證它,提案者或許會希望釋出他們的工具鏈。驗證是一種社會活動。
身份合約可用於為提案建立身份,並對其進行認證。
它很大,但RAM將被系統或被公投合約所覆蓋。
投票時間最長可開放90天。
選民可以投贊成票或反對票,或完全撤回他們的投票(這會降低“選民投票率”)。
選民通過支付RAM來儲存他們的選票;在投票結束後刪除選票。
提案中的新系統合約一旦符合以下標準,即會被採用:
保持贊成票票數至少比反對票票數多10%(即最好是55%以上的贊成票)。
保持最低10%的“選民投票率”(10%的流通token已用作投票)。
在90天內連續30天保持上述兩個標準(很明顯,如果在90天的視窗期內不能持續30天的最低標準,贊成票票數低於總數的55%或投票率低於總數的10%,提案就會當場宣告失敗)
提案通過後,安裝的Proposed Tx的新系統合約由BP簽署;一旦超過15個BP簽署,立即生效。
若是緊急升級,過程是完全不同的,本條款沒有提及此情形。
其他的意見和影響:
任何支付費用並呼叫公投合約的人都可以提出升級。
我們有不限數目的提案可供投票。如果得到多數通過,將會在通過提案中按順序實現。
《BP協議》中預計BP會進行升級;否則,將會違反其中協議,並使他們遭受爭議、損失名譽和失去選票等。
應該公開檢查系統合約的提案,以及檢查是否是由BP簽署的安裝Proposed Tx。
在不限數目的提案中,投贊成票和反對票都不受限制。
(十七)第十七條——法律的選擇
目的
建立法律解釋方面的“法律選擇”,包括仲裁,其中公約保持沉默或含糊不清。
本條內容
根據本公約,衡平法準則和馬耳他法律,法律糾紛的選擇應按優先順序排列。
討論
我一直在考慮徹底拋棄公約,讓仲裁系統管理法律選擇。經過反思,我想提供這篇文章,因為我希望社群提前知道這個話題,而不是在糾紛正在進行仲裁後才找出(比如開啟一個意外的禮物)。
顯然,這部公約是區塊鏈社群採納的最高法律。
但是公約是非常簡短的,不能預見所有的情況。每一篇文章的評論都增加了它,這將有助於仲裁員。但這是否就足夠了呢?不。
為什麼是選擇衡平法準則?
衡平法準則是一套廣為接受的格言或格言,它包含了公平與正義的觀念,特別是關於財產的觀點。Dan此前曾引用公平馬克思主義作為EOS憲法選擇法的候選人。
這些準則不是依賴於地點或依賴於文化,因此它們是為憲法文字提供備份的好選擇。
三、相關文章連結彙總
第一條:不說謊 https://steemit.com/eos/@eoshenzhen/6svnvr-eos-gov-eos-io
第二條:財產權 https://steemit.com/eos/@eoshenzhen/7f72dq-eos-gov-eos-io
第三條:仲裁 https://steemit.com/eos/@eoshenzhen/eos-gov-thomas-0-3-0-eos-io
第四條:不買賣選票 https://steemit.com/gov/@eoshenzhen/eos-gov-thomas-eos-io
第五條:不存在所有者或受託人 https://steemit.com/gov/@eoshenzhen/eos-gov-eos-io
第六條:不超過10%的所有權 https://steemit.com/eos/@eoshenzhen/eos-gov-eos-io-10
第七條:處罰協議 https://steemit.com/eos/@eoshenzhen/638kth-eos-gov-eos-io
第八條:《區塊生產者協議》https://steemit.com/eos/@eoshenzhen/2fhezd-eos-gov-eos-io
第九條:建立仲裁法庭 https://steemit.com/eos/@eoshenzhen/2ctbh5-eos-gov-eos-io
第十條:仲裁員標準 https://steemit.com/eos/@eoshenzhen/2natpt-eos-gov-eos-io
第十一條:開發人員和智慧合約許可證 https://steemit.com/eos/@eoshenzhen/3harkq-eos-gov-eos-io
第十二條:多語種合同 https://steemit.com/eos/@eoshenzhen/5sevfm-eos-gov-eos-io
第十三條:開發人員對非成員的訪問負責 https://steemit.com/eos/@eoshenzhen/42llv3-eos-gov-eos-io
第十四條:無積極權利 https://steemit.com/eos/@eoshenzhen/5ys6pn-eos-gov-eos-io
第十五條:指定預設仲裁法庭 https://steemit.com/eos/@eoshenzhen/ujlvn-eos-gov-eos-io
第十六條;修訂案 https://steemit.com/eos/@eoshenzhen/5dpeis-eos-gov-eos-io
第十七條:法律的選擇 https://busy.org/@eoshenzhen/6sppv5-eos-gov-eos-io
本文圖片來源於網路
相關文章:
關於我們更多聯絡:
Website:https://eoshenzhen.io
Steem:https://steemit.com/@eoshenzhen
Busy:https://busy.org/@eoshenzhen
Telegram:https://t.me/eoshenzhen
Twitter:https://twitter.com/eostechlover
簡書:EOS技術愛好者
新浪微博:EOSTechLover
EOShenzhen的投票賬號:eoshenzhenio
相關文章
- 關於BSC鏈智慧合約dapp開發詳情講解APP
- 關於合約跟單策略系統開發技術講解分析
- java 多執行緒(關於Thread的講解)Java執行緒thread
- 關於智慧合約馬蹄鏈DAPP系統開發技術講解(方案)APP
- 關於FDF智慧合約馬蹄鏈迴圈互助系統開發講解
- "量化合約"路線圖講解 | defi合約量化結構模式講解模式
- HTML中關於表單的講解(思維導圖)HTML
- 關於公眾號的使用
- 差分約束基本講解
- 關於前端中常用的排序演算法-圖文講解前端排序演算法
- 關於馬蹄鏈矩陣公排智慧合約系統開發功能矩陣
- 恆創科技:關於香港伺服器的三種線路講解伺服器
- 恆訊科技講解:關於網站訪問慢的檢測方法網站
- 關於外來鍵約束
- 關於C99可變引數巨集的例項程式碼講解
- Java公約公倍數Java
- 關於equals()和hashcode()的一些約定
- 公網對講SDK| 快速搭建公網對講應用
- 區塊鏈公鏈的開發丨技術講解方案區塊鏈
- Java物件公約Java物件
- Mysql 關於event的詳解MySql
- 關於FFMPEG的解碼模型模型
- P7575 「PMOI-3」公約數 題解
- 俞敏洪演講涉嫌歧視女性,再會演講的老闆都得有個牛逼的公關
- DApp智慧合約技術開發詳情講解APP
- 關於管理者上臺講話技巧
- js關於正則的前後關聯約束(前後預查)JS
- 五一勞動節,講講NEO智慧合約的除錯除錯
- 關於智慧合約的去中心化有什麼用?中心化
- Windows 關於Robocopy的使用詳解Windows
- 關於SSL裝置的詳解
- Mysql關於procedure、function的詳解MySqlFunction
- 關於Java中的@Deprecated註解Java
- 講解關於蘋果開發者賬號的三種型別以及區別有哪些蘋果型別
- 關於區塊鏈零擼專案系統開發技術(成熟講解)區塊鏈
- 量化交易系統開發之合約詳情講解
- 講課 PPT 公開啦
- 關於Java Chassis 3的契約優先(API First)開發JavaAPI