Byteball開発者向け情報wiki

これらの句は、ユニットの作者を認証します。

ここでは、単一の秘密鍵で制御されるアドレスを定義する最も単純な例を示します

["sig", {"pubkey": "Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]

上のpubkeyはbase64でエンコードされた公開鍵です。 "sig"は、トランザクションで提供された署名が有効であり、上記の公開鍵に対応する秘密鍵によって生成された場合、"true"と評価されます。この定義に対応するアドレス（base32のチェックサム付きハッシュ）は、A2WWHN7755YZVMXCBLMFWRSLKSZJN3FUです。

この節は、作成者がアドレス定義で指定されたハッシュのプリイメージを提供する場合にtrueと評価されます。

["hash", {"hash": "value of sha256 hash in base64"}]

これらの節は、他の条件を論理演算子と組み合わせることを可能にします。

この言語のすべての式はブール値に評価され、複数のブールサブ式はブール演算子andとorを使用して組み合わせることができます。
たとえば、これは2つの署名が必要な定義です。

["and", [
	["sig", {pubkey: "one pubkey in base64"}],
	["sig", {pubkey: "another pubkey in base64"}]
]]

上記の定義のハッシュと同じアドレスから資金を使うには、2つの署名を提供する必要があります。
お気付きのとおり、JSONを使用して言語表現を作成します。
これは珍しい選択ですが、既存のよくデバッグされた、よくサポートされた、最適化されたJSONパーサーを使用することは可能です。

"Or"は、リストされた公開鍵のいずれかによって署名を要求するために使用できます。

["or", [
	["sig", {pubkey: "laptop pubkey"}],
	["sig", {pubkey: "smartphone pubkey"}],
	["sig", {pubkey: "tablet pubkey"}]
]]

上記の記述例は、ラップトップ、携帯電話、タブレットの3つのデバイスのいずれかから同じアドレスを制御する場合に便利です。

条件は入れ子にすることができます：

["and", [
	["or", [
		["sig", {pubkey: "laptop pubkey"}],
		["sig", {pubkey: "tablet pubkey"}]
	]],
	["sig", {pubkey: "smartphone pubkey"}]
]]

定義では、より大きい集合の中で最小数の条件が真であることを要求することができます。たとえば、2-of-3の署名です。

["r of set", {
	required: 2,
	set: [
		["sig", {pubkey: "laptop pubkey"}],
		["sig", {pubkey: "smartphone pubkey"}],
		["sig", {pubkey: "tablet pubkey"}]
	]
}]

（「r」は「必須」を表す）、2つの必須署名のセキュリティと信頼性の両方を備えているため、鍵の1つが失われてもアドレスは引き続き使用可能であり、その定義を変更して 新しいキーで3番目のキーを紛失したり、別のアドレスに資金を移動したりすることができます。

また、異なる条件に異なる重みを与えることができ、そのうちの最小限のものが必要とされます

["weighted and", {
	required: 50,
	set: [
		{weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },
		{weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },
		{weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },
		{weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
	]
}]

後続の条件は、not節で無効にすることができます:

["not", ["in data feed", [["NOAA ADDRESS"], "wind_speed", ">", "200"]]]

非常に古い親を選択することは合法であるため（新しいデータフィード投稿が表示されない）、通常、上記のような否定的な条件と、タイムスタンプが特定の日付の後の要件とを組み合わせます。

sig、hash、 address、 cosigned by、 そして in merkleは否定できません。

これらの句は、そのサブ定義の評価を別のものにリダイレクトします。

定義には、アドレス句を使用して別のアドレスへの参照を含めることができます。

["and", [
	["address", "ADDRESS 1 IN BASE32"],
	["address", "ADDRESS 2 IN BASE32"]
]]

これは署名を別のアドレスに委任し、共有制御アドレス（契約の複数のユーザによって制御されるアドレス）を構築するのに便利です。 この構文により、ユーザーは、いつでも他のユーザーを気にすることなく、独自のコンポーネントアドレスの定義を自由に変更できます。

定義は"definition template"を参照できます

["definition template", [
	"hash of unit where the template was defined",
	{param1: "value1", param2: "value2"}
]]

パラメータは、テンプレート内で置き換えられる変数の値を指定します。 テンプレートは特別なメッセージタイプapp = "definition_template"で保存する必要があります（通常は使用前に安定している必要があります）。テンプレート自体はメッセージペイロードにあり、テンプレートは通常の定義のように見えますが、 構文@param1、@ param2。 定義テンプレートはコードの再利用を可能にします。 彼らはまた、他のテンプレートを参照することがあります。

これらの句は、現在のユニットの外部のデータを検査します。

in data feed節は、以前にByteballに格納されたデータに関するクエリを作成するために使用できます

["in data feed", [
	["ADDRESS1", "ADDRESS2", …], 
	"data feed name", 
	"=", 
	"expected value"
]]

この条件は、「データフィード名」が「期待値」に等しい、少なくとも1つの前のメッセージがByteballデータベースに格納されている場合に、真と評価されます。 =の代わりに、>、<、> =、<=、または=を使用することもできます。データフィードは、アドレスが「アドレス1」、「アドレス2」、・・・などのoracleのいずれかでByteball分散データベースに投稿する必要があります。 oraclesは共通のデータベースにポストしているので、私たちはそれらを連鎖と呼んでいます。

オンチェインoraclesは確かに非常に強力なものです。 たとえば、このアドレス定義はバイナリオプションを表します。

["or", [
	["and", [
		["address", "ADDRESS 1"],
		["in data feed", [["EXCHANGE ADDRESS"], "EURUSD", ">", "1.2500"]]
	]],
	["and", [
		["address", "ADDRESS 2"],
		["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2018-10-01 00:00:00"]]
	]]
]]

それは2つのオーラックに頼っています.1つはEUR / USD為替レートを掲示しており、もう1つは現在の時間を掲示しています。 当初、両当事者は、それぞれのステークを住所に送付することによって、この定義で定義された住所に資金を提供します。 その後、交換所で発行されたEUR / USDの為替レートが1.2500を超えると、ファーストパーティーが資金を払うことができます。 これが2018年10月1日より前に起こらず、タイムスタンプオラクルが後日投稿した場合、第2当事者はこの住所に保管されているすべての資金を掃引することができます。

もう1つの例は、商人から商品を購入する顧客であるが、その商人をあまり信用しておらず、商品が配送されない場合には彼のお金を元に戻すことを望む。 顧客は、以下によって定義される共有アドレスに支払う。

["or", [
	["and", [
		["address", "MERCHANT ADDRESS"],
		["in data feed", [["FEDEX ADDRESS"], "tracking", "=", "123456"]]
	]],
	["and", [
		["address", "BUYER ADDRESS"],
		["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]
	]]
]]

定義は、正常に配送されたすべての出荷の追跡番号を記載したFedExのオラクルによって異なります。 出荷が配送される場合、商人は最初の条件を使用してお金をロック解除することができます。 指定された日付より前に配送されない場合、顧客はお金を取り戻すことができます。 この例は、FedExが各貨物を発送する必要があるため、多少狂っています。 同じ結果を達成するためのより現実的な方法については、以下の「in merkle」節を参照してください。

"in merkle"は、大規模なデータセット内の特定のデータエントリの存在を照会するより経済的な方法です。 data_feedメッセージにすべてのデータエントリをポストする代わりに、大きなデータセットのmerkleルートのみがdata_feedとしてポストされ、署名者はデータエントリとそのmerkleパスを提供する必要があります。

["in merkle", [
	["ADDRESS1", "ADDRESS2", ...],
	"data feed name",
	"expected value"
]]

["seen address", "ANOTHER ADDRESS IN BASE32"]

この句は、指定されたアドレスが、最後の安定したユニットに含まれる少なくとも1つの過去のユニットの著者として見なされた場合、 "true"と評価されます。

["seen", {
	what: "output",
	address: "ADDRESS",
	asset: "asset or base",
	amount: 12345
}]

この句は、指定された条件を満たす過去（最後の安定した単位の前）に入力または出力があった場合に "true"と評価されます。 検索条件の構文は、以下のhas節と同じです。

["seen definition change", ["ADDRESS", "NEW DEFINITION CHASH"] ]

指定されたアドレスの定義変更があり、新しい定義のc-hash（チェックサム付きハッシュ）が指定された値と等しい場合、この句は "true"と評価されます。

これらの句は、現在のユニット内のデータを検査します。

サブディビジョンでは、トランザクションを別のアドレスによってコサインする必要があります:

["cosigned by", "ANOTHER ADDRESS IN BASE32"]

定義には、トランザクション自体に関する照会を含めることもできます。この照会は、たとえば、信頼できない交換での発注を制限するために使用できます。 ユーザーが1,000バイト（Byteballの本来の通貨）を支払うことを望んでいる資産の1,200単位を購入したいと仮定します。 また、彼は売り手を待っている間、常にオンラインにとどまっていません。 彼はちょうど交換所で注文を掲示し、一致する売り手が来たらそれを実行させます。 彼は、この定義によって定義されたアドレスに1,000バイトを送信することによって制限命令を作成することができ、これは「has」節を使用します。

["or", [
	["address", "USER ADDRESS"],
	["and", [
		["address", "EXCHANGE ADDRESS"],
		["has", {
			what: "output", 
			asset: "ID of alternative asset", 
			amount_at_least: 1200, 
			address: "USER ADDRESS"
		}]
	]]
]]

第1の代替方法は、ユーザが好きなときにいつでもバイトを取り戻すことができるため、注文を取り消すことができます。 第2の選択肢は、同じ取引の別のアウトプットが他の資産の少なくとも1,200単位をユーザの住所に支払うという条件で、取引所に資金を使う権利を委任する。 取引所は注文を公表し、売り手はそれを見つけ、資産を交換する取引を構成し、取引所と一緒にそれに署名する。 交換機は、ユーザの資金を恣意的に管理することはできず、同時に代替資産をユーザに支払う場合に限り、ユーザが資金を完全に支配し、好きなときに契約から引き出すことができる。

トランザクションに、すべての設定条件を満たす少なくとも1つの入力または出力がある場合、「has」句は「true」と評価されます。

• what:「input」か「output」が必要です。
• asset:IDのアセット(44文字の文字列)か、Bytes支払いを示す「base」
• type:入力専用で、「transfer」か「issue」。指定されている場合は、「transfer」または「issue」のみが検索されます。
• own_funds:入力専用で、「true」か「false」。このアドレスに保管された資金を使う入力が必要な場合は「true」に設定します（アドレスはトランザクションに署名することもできますが、何も費やすことはできません。他の貸し手アドレスは資金を提供します）
• amount_at_least,amount_at_most,amount:amountは指定された値と少なくとも同じか、多くても正確にも等しい必要があります
• address:出力が送信されるアドレスまたは入力が使用されるアドレス。

類似の節「has one」は構文が全く同じですが、検索条件を満たす入力または出力が1つだけある場合はtrueと評価されます。

以下の要件は、さらに、下位定義に含めることもできます:

["has equal", {
	equal_fields: ["address", "amount"],
	search_criteria: [
		{what: "output", asset: "asset1", address: "ADDRESS IN BASE32"},
		{what: "input", asset: "asset2", type: "issue", own_funds: true, address: "ANOTHER ADDRESS IN BASE32"}
	]
}]

検索条件を満たす入力または出力のペアが少なくとも1つあり、 "equal_fields"で指定されたフィールドが等しい場合は、 "true"と評価されます。 ペアの最初の要素は最初のフィルタセットで検索され、2番目のフィルタは2番目の要素で検索され、検索条件の構文は "has"句と同じです。

同様の条件「has one equal」は、そのようなペアが1つだけ存在することを要求する。

この句は、フィルタを満足する入力または出力の合計が少なくとも目標値以上であれば「真」と評価されます。

["sum", {
	filter: {
		what: "input"|"output", asset: "asset or base", type: "transfer"|"issue", own_funds: true,
		address: "ADDRESS IN BASE32"
	},
	at_least: 120,
	at_most: 130,
	equals: 123
}]

フィルタの構文は、has句と同じです。

["has definition change", ["ADDRESS", "NEW DEFINITION CHASH"] ]

ユニットが指定されたアドレスの定義変更を持ち、新しい定義のc-hash（チェックサム付きハッシュ）が指定された値と等しい場合、この句は "true"と評価されます。

["mci", ">", 123456]

現在のユニットのlast_ball_mciが（指定可能な他の比較：> =、<、<=、=）より大きい場合、この句は "true"と評価されます。 将来のいくつかのポイントの後でのみアドレスを消費可能にし、タイムスタンプや敬語には依存しないようにすると便利です。