شكرًا لك Google: كيفية استخراج Bitcoin على BigQuery من Google

تسخير قوة SQL لاستخراج العملة المشفرة في السحابة

أنا أحب جوجل BigQuery. إنه نظام بيانات مُدار وقابل للتوسعة بدرجة كبيرة ، مما يعني أنه يمكنك الاستعلام عن كميات هائلة من البيانات بسرعة كبيرة (على سبيل المثال 4 تيرابايت في أقل من 30 ثانية!). أنا أستخدمها بانتظام في مشاريعي (مثل Spanish Lesson Action لمساعد Google) ، وأنا مندهش دائمًا من الأداء العالي.

في الأسبوع الماضي ، نظمنا Dev.IL Meetup حول Blockchain ، التكنولوجيا وراء Bitcoin ، وقد أدهشني أحد المحادثات من Asaf Nadler ، موضحا الآليات الكامنة وراء التكنولوجيا التي تجعل Bitcoin التجزئة (لا تتردد في مشاهدة الحديث هنا ، ولكن تحذير عادلة ، في العبرية :-). عندما عدت إلى المنزل بعد الاجتماع ، كانت وحدة التحكم في BigQuery مفتوحة مع بعض استعلام التحليلات الذي كتبته في اليوم السابق ، وحصلت على هذه الفكرة: ماذا لو كان بإمكاني استخدام BigQuery لاستخراج Bitcoin؟ هل هو ممكن حتى؟ يمكن أن يكون هذا فعالة من حيث التكلفة؟ بالنظر إلى قابلية تطوير BigQuery للإعجاب ، فقد بدا أنها قد تكون مباراة جيدة.

(المفسد: لقد كان ما يصل إلى 25 جيجا - تجزئة / ثانية ، مجانية ، وممتعة للغاية! تابع القراءة لمعرفة كيف ...)

كنت مفتونًا جدًا ، ولذا قررت أن أجربه. لقد كنت مهتمًا بتجربة تقنية Blockchain لفترة من الوقت ، وكانت هذه فرصة رائعة للقيام بذلك. استغرق الأمر قراءة الكثير من المقالات وساعات قليلة من العمل ، لكنني حققت بعض النجاح! (أو بالأحرى نجاح إثبات المفهوم ؛-)

اعتقدت أنه قد يكون من المثير للاهتمام أن أشارككم رحلتي معك في تحويل جهاز تحليل البيانات إلى آلة تعدين Bitcoin. لقد فوجئت تماما بالنتائج. وأراهن أنك ستكون كذلك!

لكن أول الأشياء أولاً: دعنا نلقي نظرة سريعة فائقة على كيفية عمل تعدين Bitcoin.

التعدين Bitcoins في باختصار

ربما تكون قد سمعت أن تعدين Bitcoin ينطوي على حل مشكلة حسابية صعبة من الناحية الحسابية ، وهذا صحيح: يتكون نظام Bitcoin من معاملات (أي ، تحويل الأموال بين المستخدمين) ، ويتم تسجيل هذه المعاملات في دفتر الأستاذ العام ، وتسمى blockchain. إن blockchain ، كما يوحي الاسم ، عبارة عن قائمة مرتبطة بكتل بيانات المعاملة.

يتضمن تعدين Bitcoin أساسًا العثور على كتلة تالية صالحة ، والتي بدورها تمنحك ، عامل المناجم ، جائزة - حاليًا ، 12.5BTC لكل كتلة تعثر عليها.

كل كتلة تتكون من جزأين: رأس 80 بايت ، تليها قائمة من المعاملات. يتضمن الرأس معرف الكتلة السابقة (أي تجزئة رأس المجموعة السابقة) ، بالإضافة إلى تجزئة SHA256 لقائمة المعاملات بالإضافة إلى بعض المعلومات الأخرى. بصفتك من عمال المناجم ، يتعين عليك بشكل أساسي التأكد من أن رأس الكتلة ، عند تجزئته مرتين باستخدام دالة التجزئة SHA256 ، أصغر من رقم معين ، ويشار إليه أيضًا باسم "الصعوبة" - أو مدى صعوبة العثور على الهدف رقم (أي كتلة صالحة التالية).

يتم استخراج كتل البيتكوين بمعدل حوالي كتلة واحدة في كل 10 دقائق. من أجل ضمان بقاء المعدل ثابتًا ، يتم ضبط الصعوبة تلقائيًا كل كتل عام 2016 (تقريبًا كل أسبوعين) ، لذا فهي تتناسب بشكل أو بآخر مع إجمالي عمال المناجم الذين يستخدمون الطاقة الحاسوبية في العملية.

يتضمن التعدين بشكل أساسي تجربة أشكال مختلفة للرأس ، خاصةً في الحقل nonce (آخر 4 بايت من الرأس) حتى تجد في نهاية الأمر رأسًا يبدأ التجزئة الخاص به بعدد معين من الأصفار (أو لوضعه بشكل مختلف - أصغر من البعض رقم ، كما ذكرت من قبل).

إذا كنت تريد شرحًا أكثر تفصيلًا ، فيمكنك الاطلاع على منشور مدونة Ken Shirriff حول تعدين Bitcoin ، أو المتابعة ببساطة وجمع المعلومات التي أذكرها خلال المنشور.

التعدين مع BigQuery

أنت مدعو إلى اتباع خطواتي وتشغيل الأمثلة في هذه المدونة. بعض الاستعلامات المقدمة هنا قد تشبه أجزاء من عملية التعدين Bitcoin. إذا كان لديك حساب تجريبي في Google Cloud Platform Free ، فإن شروطهم تحظر عليك المشاركة في التعدين باستخدام cryptocurrency. على الرغم من أن أيًا من الأمثلة المقدمة في هذا المنشور لن يستثني أي عملة مشفرة فعليًا ، إلا أنني لا زلت أنصح باستخدامها بطريقة آمنة ولدي حساب Google Cloud Platform مدفوع ، وهو ، على حد علمي ، لا يحظر تعدين العملات المشفرة بأي طريقة.

أول الأشياء أولاً: النظر إلى رأس الكتلة

لنبدأ من خلال النظر في كيفية القيام بالتعدين في الممارسة العملية. سوف نلقي نظرة على رأس بعض الكتل من Bitcoin blockchain وسنحاول حساب البعثرة لأنفسنا ليرى كيف يتم ذلك (ثم نتحقق أيضًا من إمكانية قيامنا بجزء التجزئة باستخدام BigQuery).

ولكن أين نجد كتلة؟

تبين ، يمكنك العثور على Blockchain بالكامل في BigQuery. ولكن لأغراضنا ، سنستخدم مصدرًا مختلفًا ، والذي يوفر أيضًا وسيلة للحصول على البيانات الثنائية الأولية للكتلة: موقع إلكتروني يسمى blockchain.info. لقد اخترت عشوائيًا إحدى الكتل الحديثة ، رقم 514868:

يمكنك الحصول على البيانات الثنائية لهذا الحظر (تشفير سداسي عشرية) ، عن طريق النقر فوق تجزئة الكتلة ، ثم إلحاقها؟ format = hex to URL ، مما يؤدي إلى هذا الرابط. تعرض طريقة العرض block أيضًا القائمة الكاملة للمعاملات والبيانات الأخرى المثيرة للاهتمام ، وأدعوك لاستكشافها بنفسك.

في الوقت الحالي ، على الرغم من ذلك ، دعونا نستمر في التركيز على الرأس. سنقوم بنسخ أول 160 حرفًا من بيانات الكتلة (ستكون أول 80 بايت):

000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d670832000000000000000000f99f5c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79fdbc5e491b55a494a5117ac997500

تشرح صفحة Bitcoin Wiki هذه الطريقة التي تعمل بها خوارزمية التجزئة: نحتاج أساسًا إلى أخذ هذا الرأس وتشغيل دالة SHA256 عليه ، ثم تشغيله مرة أخرى على نتيجة التشغيل الأول. هذا يجب أن يؤدي إلى تجزئة الكتلة.

أول شيء ، إذا أردنا القيام بذلك في BigQuery ، فسنحتاج إلى وظيفة SHA256. لحسن الحظ ، تم تقديمه في الإصدار 2 من BigQuery (a.k.a Standard SQ). نحتاج أيضًا إلى طريقة لتحويل قيم سداسي عشرية هذه إلى وحدات بايت حقيقية. لحسن الحظ ، حصلت على وظيفة تسمى FROM_HEX تغطيتها. حتى الان جيدة جدا.

الآن يمكننا تجربة كتابة الاستعلام الفعلي (كسطر واحد):

اختر TO_HEX (SHA256 (SHA256 (FROM_HEX (
"000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d670832000000000000000000f99f5c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79fdbc5e491b55a494a5117ac997500 '))))

(إذا كنت ترغب في المتابعة معًا ، يمكنك محاولة تشغيل هذا الاستعلام على وحدة التحكم BigQuery. ستحتاج أيضًا إلى إلغاء تحديد خيارات استعلام "Use Legacy SQL". إذا حصلت على خطأ نصه: "وظيفة غير معروفة to_hex" ، يعني أنك لم تقم بإلغاء تحديد هذا المربع.)

عن طريق تشغيل الاستعلام أعلاه ، نحصل على النتيجة التالية:

كنت أتوقع أن أرى

عندما فعلت هذا في المرة الأولى ، شعرت بخيبة أمل كبيرة ، لأنه يبدو أن التجزئة كان مختلفًا عن التجزئة الأصلية للكتلة. لكنني أدركت بسرعة أنه تم عكس ذلك! (على ما يبدو ، يتم تخزين التجزئة Bitcoin القليل endian).

أدت إضافة دالة REVERSE قبل الاتصال بـ TO_HEX إلى الحيلة:

اختر TO_HEX (العكسي (SHA256 (SHA256 (FROM_HEX (
"000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d670832000000000000000000f99f5c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79fdbc5e491b55a494a5117ac997500 ')))))
الآن يبدو شرعي!

هذا إنجاز كبير بالفعل: نعلم الآن أنه يمكننا التحقق من تجزئة كتل Bitcoin في BigQuery. إذا أردنا استخدام BigQuery للأعمال المتعلقة بالألغام ، فسنريد استخدام نفس المجموعة من الوظائف ، باستثناء أننا لن نحصل على العنوان الكامل: سيتعين علينا البحث عن رأس صالح ذي قيمة تجزئة صغيرة كافية.

يتكون رأس صالح من 6 حقول:

  1. الإصدار - قيم 2 و 3 و 4 شائعة (تتم إضافة قيم جديدة)
  2. hashPrevBlock - تجزئة الكتلة السابقة في السلسلة
  3. hashMerkleRoot - تجزئة جميع المعاملات في كتلة (الشرح)
  4. الوقت - الطابع الزمني للوقت الذي تم فيه إنشاء الكتلة
  5. صعوبة - صعوبة الكتلة المخزنة كرقم النقطة العائمة
  6. nonce - 4 بايت يمكننا تغييرها للتأثير على قيمة الرأس

يحاول التعدين بشكل أساسي كافة التوليفات الممكنة لـ nonce ، ومن ثم التحقق من التجزئة لكل منها حتى تكون التجزئة أقل من القيمة المستهدفة. يمكن استخلاص القيمة المستهدفة بسهولة من صعوبة الكتلة:

الهدف = (0xffff * 2 ** (256-48)) / الصعوبة

الحد الأدنى من الصعوبة لأي كتلة هو 1. لذلك ، فإن أي هدف سيكون لديه ما لا يقل عن 48 أصفار بادئة. لذا ، نظرًا لأن رقم الصعوبة الخاص بنا كان 3462542391191.563 ، كان الهدف: 000000000000000000514a490000000000000000000000000000000000000000

يمكنك العثور على الصعوبة الحالية والقيمة المستهدفة هنا (سيعطيك الرابط أيضًا شرحًا أكثر قليلاً حول العلاقة بين الصعوبة والقيمة المستهدفة).

لذلك ، في الأساس ، إذا أردنا إعادة إنتاج عملية التعدين لهذه الكتلة ، فسوف نضطر فقط إلى تجربة جميع المجموعات المختلفة لـ nonce ، آخر 4 بايت من الرأس ، حتى وجدنا واحدة لها تجزئة أصغر من أعلاه رقم.

إعادة التعدين الكتلة

قررت أن أبدأ صغيرًا بالبحث فقط عن البايت الأخير ، حيث لدينا بالفعل الإجابة في هذه الحالة. في البداية كنت أفكر في تحميل جدول صغير به جميع الأرقام بين 0 و 255 (القيم الصالحة لتلك البايتة) ، ولكن بعد ذلك وجدت أنه يمكن محاكاة هذا الجدول من خلال دمج وظيفتي SQL: UNNEST () و GENERATE_ARRAY ():

SELECT * FROM UNNEST (GENERATE_ARRAY (0، 255)) num؛

مسلحًا بهذه المعرفة ، قمتُ بإنشاء أول استعلام لي حاول إعادة إنتاج عملية التعدين داخل BigQuery:

تحديد
  TO_HEX (CODE_POINTS_TO_BYTES ([0xac، 0x99، 0x75، num])) AS nonce
من عند
  UNNEST (GENERATE_ARRAY (0، 255)) num
أين
  TO_HEX (REVERSE (SHA256 (SHA256 (CONCAT (FROM_HEX (
"000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d670832000000000000000000f99f5c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79fdbc5e491b55a494a5117 ')، CODE_POINTS_TO_BYTES ([0xac، 0x99، 0x75، الأسطوانات])))))) LIKE' 000000000000000000٪ '

حسنًا ، دعنا نضايق ذلك قليلاً!

نظرًا لأننا نبحث فقط عن الصحيح ، فقد قمت بإزالة هذا الجزء من الرأس (يمكنك التحقق من ذلك - طول السلسلة السداسية العشرية في الاستعلام يبلغ طوله 152 حرفًا فقط ، وهو ما يمثل 76 بايت ، أي الرأس بدون حالية). ما يبحث عنه استعلامنا هو قيمة 4 بايت والتي ، بمجرد إلحاقها بالرأس ، ستؤدي إلى تجزئة أصغر من الرقم الهدف.

نظرًا لأن هذه كانت تجربتي الأولية ، فقد استخدمت القيم التي أعرفها بالفعل من الكتلة لأول 3 بايتات في nonce ، وكان لديّ فقط البحث في BigQuery عن البايت النهائي. لقد كان هذا بمثابة سحر ، وسرعان ما وجد القيمة الصحيحة nonce:

قد تتساءل عن سبب استخدام LIKE داخل جملة WHERE لتصفية النتيجة الصحيحة. أفعل ذلك لأننا نبحث ببساطة عن تجزئة أصغر من القيمة المستهدفة. نظرًا لأن القيمة المستهدفة تبدأ بـ 18 أصفارًا ، فنحن ببساطة نقوم بتصفية أي رقم لا يبدأ بـ 18 أصفار (لأنه من الواضح أنه أكبر من القيمة المستهدفة). هذا يعني أننا قد نحصل على بعض الإيجابيات الخاطئة (على سبيل المثال ، العدد الذي يبدأ بـ 18 أصفارًا ثم أي رقم يزيد عن 5) ، ولكن يمكننا تصفية هذه البيانات يدويًا بسرعة.

حتى الآن ، عندما نعرف كيفية البحث عن nonce متستر ، يمكننا توسيع البحث بسرعة إلى المزيد من بايت:

تحديد
  TO_HEX (CODE_POINTS_TO_BYTES ([0xac، num2، num3، num4])) AS nonce
من عند
  UNNEST (GENERATE_ARRAY (0 ، 255)) num2 ،
  UNNEST (GENERATE_ARRAY (0 ، 255)) num3 ،
  UNNEST (GENERATE_ARRAY (0 ، 255)) num4
أين
  TO_HEX (REVERSE (SHA256 (SHA256 (CONCAT (FROM_HEX (
"000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d670832000000000000000000f99f5c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79fdbc5e491b55a494a5117 ')، CODE_POINTS_TO_BYTES ([0xac، NUM2، num3، num4])))))) LIKE' 000000000000000000٪ '

أثناء قيام هذا الاستعلام بالخدعة والعثور على 3 بايت ، كانت هناك مشكلة واحدة: إنها بطيئة! استغرق هذا الاستعلام حوالي 30 ثانية لإكماله. إذا أردنا البحث عن جميع وحدات البايت الأربع ، فسيستغرق الأمر ساعتين تقريبًا بهذه السرعة. لقد ذكرت أعلاه أن هناك كتلة جديدة تستخرج كل 10 دقائق ، لذلك بحلول الوقت الذي وجدنا فيه نتيجة ، كنا بالفعل متخلفين ولن يكون ذلك مناسبًا.

كان هذا مخيبا للآمال بعض الشيء (ماذا حدث لوعد BigQuery "القابل للتطوير بدرجة كبيرة؟" ، لذلك قررت أن أستكشف أكثر وأحاول أن أرى ما إذا كان بإمكاني القيام بأي شيء لتحسين ذلك.

من تجربتي السابقة في BigQuery ، تذكرت أن الانضمام إلى طاولات مختلفة كان عملية مكلفة تسببت في تشغيل الاستعلامات لفترة أطول. لقد حاولت إزالة خطوة الانضمام عن طريق إنشاء جدول أكبر (على سبيل المثال ، إخبار GENERATE_ARRAY بإنشاء المزيد من الأرقام) ، ولكن بعد إجراء بعض التجارب والخطأ ، بدا أن الحجم الأقصى للجدول سيظل حوالي مليون صف ، مما يعني أنني ' لا يزال يتعين عليك الانضمام إلى الجداول أو البحث فقط عن مليون تجزئة في كل مرة (وهو نوع من العبث ، حيث يمكن لوحدة المعالجة المركزية لجهاز الكمبيوتر الخاص بي القيام بذلك في أقل من ثانية).

لذلك يبدو أنه سيكون من الممكن تعدين Bitcoin باستخدام BigQuery ، ولكن بالكاد عملي.

ومع ذلك ، لست مولعًا جدًا بالاستسلام ، لذا جربت بعض الطرق الأخرى. واحد منهم يعمل فعلا!

التعدين أسرع

تذكرت أن BigQuery لديها بعض مجموعات البيانات العامة الكبيرة جدًا التي تحتوي على جداول هائلة. بعد مسح عدد قليل منها ، وجدت واحدة تحتوي على 5.3 مليار صف ، وهو ما يزيد قليلاً عن 4،294،967،296 ، وهو عدد مختلف مجموعات من nonce. إذا تمكنت من إنشاء استعلام يمتد فوق هذا الجدول وتجربة مجموعة مختلفة لكل صف في الجدول ، فسأكون قادرًا على تغطية جميع المجموعات المحتملة.

لقد حاولت استخدام دالة SQL ROW_NUMBER () OVER () لهذا الغرض ، والتي يجب أن تُرجع رقم الصف الحالي (ثم يمكنني استنباط مجموعة مختلفة من البايتات لكل صف ، وفقًا لرقم الصف) ، لكن سرعان ما تلاشت مع الخطأ التالي:

الموارد التي تم تجاوزها أثناء تنفيذ الاستعلام: تعذر تنفيذ الاستعلام في الذاكرة المخصصة ..

المشكله! لكن بعد ذلك ، بدأت أفكر - ماذا لو جربت الأرقام العشوائية؟ في النهاية ، هناك فرصة جيدة جدًا أنه إذا كان هناك تجزئة مطابقة ، فسوف أجدها ، لأن عدد المحاولات أكبر من عدد المجموعات.

لذلك ، توصلت إلى هذا الاستعلام:

اختر TO_HEX (nonce)
من عند (
  تحديد
    CODE_POINTS_TO_BYTES ([
      CAST (TRUNC (256 * RAND ()) AS INT64) ،
      CAST (TRUNC (256 * RAND ()) AS INT64) ،
      CAST (TRUNC (256 * RAND ()) AS INT64) ،
      CAST (TRUNC (256 * RAND ()) AS INT64)
    ]) كما نونسي
  من عند
    `FH-bigquery.wikipedia.wikipedia_views_201308`
)
أين
  TO_HEX (REVERSE (SHA256 (SHA256 (CONCAT (FROM_HEX (
'000000204a4ef98461ee26898076e6a2cfc7c764d02b5f8d6708320000000000000000999955c4d5025979fcb33d245536a55b628d4564c075c0210cbbc941ad79)

ينشئ CAST (TRUNC (256 * RAND ()) AS INT64) رقمًا عشوائيًا بين 0 و 255 ، ثم يقوم الجزء SELECT الداخلي ببساطة بإنشاء جدول يحتوي على 5.3 مليار صف تقريبًا من أربع قيم عشوائية. ثم يتأكد الاستعلام الخارجي من حصولنا فقط على قيم تؤدي فعليًا إلى تجزئة منخفضة بدرجة كافية - وهو ما نبحث عنه!

لدهشتي السارة ، عاد هذا الاستعلام في غضون 20.9 ثانية فقط - ووجد بالفعل القيمة غير الصحيحة الصحيحة (حتى وجدتها مرتين!):

هذا يعني أنني تمكنت من فحص ما يقرب من 4 مليارات تجزئة في 20 ثانية ، أو حوالي 200 ميجا تجزئة في الثانية. هذا ليس سيئًا للغاية - نظرًا لأن وحدات معالجة الرسومات (GPU) لن تحصل إلا على حوالي 30 إلى 60 ميجا بايت / ثانية (وحدات المعالجة المركزية أقل ، ناهيك عن التعدين بالقلم الرصاص والورق).

من الواضح ، أن هذا لن يجعلنا في أي مكان بالقرب من أجهزة التعدين المخصصة للسرعة ، ولكن لا يزال هناك خدعة أخرى كانت لدي تحت جعبتي ...

التزامن

إذا كنت مدافعًا في أدوات التجميع ، فقد تلاحظ أن التحقق من جميع القيم المحتملة لـ nonce لا يضمن فرصة جيدة جدًا للعثور على علامة تجزئة صغيرة بما يكفي (كما قلت في البداية ، إنها مشكلة صعبة!).

في وقت كتابة هذا التقرير ، كان الهدف عبارة عن 2¹⁸² تقريبًا (راجع كيف نحسب الهدف من الصعوبة أعلاه) ، مما يعني أن هناك مجموعات صالحة للتجزئة تبلغ 2 out² من إجمالي 2²⁵⁶ ممكن ، أو بعبارة أخرى - فرصة أن تكون التجزئة العشوائية أقل من الهدف هو 1 في 2⁷⁴.

هذا يعني في الأساس أننا إذا قمنا بتغيير nonce فقط ، فسوف نتحقق من إمكانيات 2³² ، وفرصتنا لإيجاد علامة التجزئة المطلوبة صغيرة جدًا: لذلك نحن بحاجة إلى المزيد من وحدات البايت للعب بها.

إذا ألقينا نظرة أخرى على هيكل الرأس ، فستلاحظ أنه يمكننا تغيير مجال الوقت قليلاً (ستظل العقد الأخرى تقبل الحظر في حالة توقف الوقت قليلاً) ، أو يمكننا تغيير شيء ما في قائمة معاملات الكتلة الخاصة بنا ، والتي سوف ينتج عنها قيمة مختلفة تمامًا لحقل تجزئة جذر ميركل.

تتمثل إحدى طرق تغيير قائمة المعاملات (وبالتالي إنشاء تجزئة merkle مختلفة) في إضافة حمولة إضافية إلى المعاملة الأولى ، تسمى extraNonce ، والتي يمكن أن تحتوي على ما يصل إلى 100 بايت. هناك طريقة أخرى تتمثل في اختيار مجموعة مختلفة من المعاملات لتضمينها في الكتلة.

هذه النقطة هي ، من أجل أن تكون منجمًا ناجحًا ، يتعين على المرء تجربة مجموعات مختلفة من قائمة المعاملات و / أو تغيير مجال الوقت ، بالإضافة إلى nonce. هذا يعني أنه يمكننا تشغيل الاستعلام الذي وجدناه عدة مرات ، بالتوازي ، في كل مرة مع رأس كتلة مختلفة. ولكن كم عدد الاستعلامات المتزامنة التي تسمح بها BigQuery؟

وفقًا لصفحة الحصص ، يمكنك قراءة ما يصل إلى 50 استفسارًا متزامنًا ، مما قد يؤدي ، من الناحية النظرية ، إلى تجزئة أسرع تصل إلى 50 مرة. هل حقا العمل؟ لا أعرف ، لم أحاول. حاليًا ، كانت أفضل نتيجة لاستعلام واحد هي 500 ميجا تجزئة في الثانية (باستخدام مجموعة بيانات ويكيبيديا البالغة 106 مليارات صف كجدول مصدر) ، مما يعني أنه بحد أقصى 50 استفسارًا متزامنًا ، يمكننا الحصول نظريًا على ما يصل إلى 25 جيجا التجزئة / ثانية. مثل أجهزة التعدين المخصصة المعتدلة - وهي ليست سيئة للغاية ، معتبرة أنها مجانية بشكل أساسي.

لذلك ، كم يكلف؟

تدعي BigQuery أنها حل فعال من حيث التكلفة. في الوقت الحالي ، كنت مقتنعًا بالفعل بادعاء قابلية التوسع ، لكن هيكل التسعير الخاص بهم كان مفاجأة لي أيضًا. مفاجأة جيدة جدا.

يعتمد نموذج التسعير الخاص بـ BigQuery فقط على مقدار البيانات التي تستفسر عنها: يتم محاسبتك أساسًا على البايت. الأمر هو أنك لا تستخدم نظام الفوترة في قوة المعالجة أو أي بيانات وسيطة أنشأها الاستعلام - فقط للبايت التي تقرأها من الجدول المصدر.

في حالتنا ، نستخدم جداول مصادر هائلة ، لكننا نستخدمها فقط لإنشاء عدد كبير من مجموعات الأرقام العشوائية - لا نقرأ فعليًا أي بيانات للجداول. يحتوي BigQuery على ميزة لطيفة حيث يعرض السعر المقدر للاستعلام (حيث يكون عدد البايتات التي ستتم محاسبتك عليها). أول 1 تيرابايت مجاني كل شهر ، وتدفع 5 دولارات لكل تبايت إضافي تسأل عنه بعد ذلك. ليس سيئا!

لذلك ، إذا تحققنا من تقديرات BigQuery للاستعلام الكبير الخاص بنا ، فهذا ما نجده:

لذلك بشكل أساسي ، يمكننا تشغيل العديد من الاستعلامات كما نريد ، مجانًا! يقيسون بالتأكيد مطالبتهم بفعالية التكلفة (في هذه الحالة ، على الأقل).

الملخص والاستنتاجات

بدأ هذا كتمرين ممتع ، بهدف معرفة كيفية عمل blockchain بشكل أفضل. عندما بدأت ، كنت متأكدًا تمامًا من أنني سأصل إلى حد كبير (ربما بعض الحصص الزمنية لوحدة المعالجة المركزية أو شيء ما) ، ويجب أن أقول أنني ما زلت مندهشًا جدًا من إمكانية الحصول على كل هذه القوة الحسابية مجانًا.

بينما يوضح بحثي أنه يجب أن يكون من الممكن تحويل BigQuery إلى آلة تعدين من الناحية النظرية ، لا يزال هناك قدر كبير من العمل الذي يجب القيام به إذا كنت أرغب في أتمتة عملية التعدين. تظهر عملية حسابية خامسة أنه حتى إذا تم بناء مثل هذا المنجم ، فعند منافسة جميع أجهزة التعدين المخصصة التي تعمل في جميع أنحاء العالم ، فإن ذلك سيجعلني تقريبًا 5 دولارات سنويًا. ومع ذلك ، الآن أعلم أنه يمكن استخراج Bitcoin باستخدام SQL ، والذي لا يقدر بثمن ؛-)

ولكن الأهم من ذلك ، أن هذه التجربة أعطتني منظوراً جديداً بالكامل حول قوة الحوسبة الهائلة التي يتم إنفاقها على استخراج البيتكوين. نحن نتحدث عن 26 مليار جيجا في الثانية - أي 2.6 * 10¹⁹ ، أي أكثر من عدد حبيبات الرمل على الأرض. كل ثانية. عليك أن تتساءل عما سنحققه إذا استخدمنا حتى جزءًا صغيرًا من هذه القوة الحاسوبية لإجراء البحوث الطبية بدلاً من ذلك ...