More than 1 year has passed since last update.

ElixirAdvent Calendar 2022

[翻訳] ②Web3＋DID＋エッジコンピューティング：Brooklyn Zelenka and The Exciting World of Edge Computing

Last updated at 2022-12-21Posted at 2022-02-14

piacere です、ご覧いただいてありがとございます
I'm piacere, the 4 Elixir communities founder/organizer, thank you for reading!

前回に続き、今回もElixir界のエッジコンピュータと惑星間ファイルシステム、DIDの専門家、Brooklyn ZelenkaのElixirエッジコンピューティングPodcast「Brooklyn Zelenka and The Exciting World of Edge Computing」の翻訳をお届けします（下図はElixirConf EU 2020でのお姿）

このPodcast翻訳シリーズの目次は下記です

[翻訳] ①Brooklyn Zelenka and The Exciting World of Edge Computing
|> [翻訳] ②Brooklyn Zelenka and The Exciting World of Edge Computing
|> [翻訳] ③Brooklyn Zelenka and The Exciting World of Edge Computing
|> [翻訳] ④Brooklyn Zelenka and The Exciting World of Edge Computing

There are 16 Elixir Advent Calendar, making for a hot winter!

We are experiencing an unprecedented level of excitement ... Please support/subscribe

https://qiita.com/advent-calendar/2022/elixir

信頼はどこで機能する？

DI: The old style brain of mine is wondering about security and protecting from a malicious somebody malicious on the network, because we've talked about no centralized trust, so where does the trust play in, in that scenario?

BZ: Yeah. Absolutely, so when we were first exploring this space, we're looking at the tools that existed. That was the big glaring hole, right? That nobody had solved. We spent a bunch of time investing in exactly that. Users control all of their data or whoever originates the data that could also be to a company or whoever, right? Each bit of data gets encrypted directly. Now, in order to get into any particular file, you need it's key and this is the same level of security as you'd get with top secret clearance for US military, right? So very high security all baked into browsers these days, it turns out actually.

Some techniques, for example one called a crypt tree that lets you avoid having to manage thousands of these keys, right? You can only have one or two and then that will manage quite a few more for you. The upshot of this is, even today, when you have data sitting behind a server that has some check to say, okay you have the right bearer token to see this record in the database, there's data breaches all the time, right? You can have bad authorization logic, people can get into the server, you can have a disgruntled employee, download a copy and release it. This happens literally on a daily basis.

DI: There's a good chance, someone listening to this podcast right now, just got an email about a data breach.

BZ: Exactly, yeah. By breaking it up into this more granular system where every file, every directory has its own keys, it's a minimizing of trust, so that we're no longer saying it's this server that needs to do all of the heavy lifting. It's baked right into the data, even as it's moving around in the network. As a service provider, say Fission, or whoever down the road, it like Twitter were to do something like this, they could also hold private data without being able to see what's inside of it. If someone were to get, into to say, my account, they wouldn't get into your account. It really minimizes the blast radius of a data breach.

DI: Wow. Okay, so super interesting.

DI：私の古いタイプの脳は、セキュリティについて、ネットワーク上の悪意ある誰かから守ることについて疑問を抱いています。中央集権的（訳注：「Centralized」、その反対はDIDにも使われるDecentralized）な信頼がないという話をしましたが、このシナリオでは信頼はどのように働くのでしょうか？

BZ：はい。まさに、私達がこの分野を最初に探求したとき、既存のツールに注目しました。そこには大きく明らかな穴がありました。誰もそれを解決していなかったのです。私達は、まさにその点に時間をかけて投資してきました。ユーザが自分のデータを全て管理するか、あるいはデータの発信元が誰であれ、企業であれ誰であれ、そのデータを管理します、そうですよね？データの各ビットは直接暗号化されます。特定のファイルにアクセスするためには、そのファイルの鍵が必要です。これは米軍の最高機密扱いと同じレベルのセキュリティです。だから最近のブラウザには、非常に高いセキュリティが全て組み込まれているのです

たとえば、クリプトツリーと呼ばれる技術では、何千もの鍵を管理する必要がありませんよね？1つか2つだけ持っていれば、あとはかなりの数の鍵を管理することができます。この結果、今日でも、データをサーバに置いて、そのサーバがDB内のレコードを見るための正しいBearerトークンを持っているかどうかをチェックする場合、常にデータ侵害が発生していることになります。不正な認証ロジックがあったり、サーバに侵入されたり、不満を持った従業員がコピーをダウンロードして公開したりする可能性があります。これは文字通り日常茶飯事です

DI：今、このPodcastを聴いている人の中にも、データ侵害に関するメールを受け取った人がいるかもしれませんね

BZ：その通りです。各ファイルやディレクトリがそれぞれ独自の鍵を持つような、より粒度の細かいシステムに分割することで、信頼を最小化し、もはやこのサーバが全ての重荷を背負う必要は無くなります。ネットワーク上を移動するデータにも、その鍵が埋め込まれているのです。サービス・プロバイダとして、たとえば Fission や、将来的には他の企業も、Twitterがしているように、中身を見ることなく個人データを持てます。誰かが私のアカウントを奪ったとしても、あなたのアカウントにはアクセスできません。それは、データ流出時の爆発半径を最小限に抑えることを可能とします

DI：ワォ。オーケー、とても興味深いですね

イミュータブルが分散コンピューティングに有利なElixir

DI: Pull us a little bit back towards Elixir. I know we talked about this is very much in the browser product. Probably not using Elixir for a lot of this implementation. Curious about functional programming styles, if that plays into how you think about this, if that has influenced the style of an edge app?

BZ: Yes, definitely. We're really focused on the browser, or at least have been, but there's nothing preventing you from being able to you've solved the really hard problems, right? So you can now walk this back into Edge PoPs, or all the way up to cloud, right? You can run this and say, it will be less. Really, the backbone of all this stuff is distributed systems, which Elixir is very good at. I would say, it even encourages you to think this way, right? The actual model, if you have process locally, or process remotely, they're not identical, but they're pretty similar, right?

A lot of people in the ecosystem, so not just the language and the tools itself, but actually the people working on projects are interested in these things, right? There's a lot of people who are doing CRDTs or Broadway as a project. Actually, doing things in high parallel or moving data around between machines, it's like the exact space where we're playing in functional programming broadly for this is a huge help, because you can't have some central resource when you're doing work. You can, but it becomes a bottleneck, right? When you're doing these distributed systems.

One of the major downsides of object oriented programming is that it hides state behind interfaces and they're locked there in space, right? You have to go over here to this machine at this address and find it. Functional programming exposes states and moves it around that way. Even in say, a gen server, right, we're always exposing, well, this is the current state that I'm going to update, and then I'll return the new one, right? We pass things around. Yes, sometimes there will be in an actor over here, there's a bit of say, and that's going to manage it, but we can also pull that out and move the data around and that's completely okay.

We can copy it, send versions somewhere else, receive more of it and that entire model works really, really well when you're thinking in factors and in immutable data structures, especially. Mutability is very difficult when doing distributed systems and having that baked in as, I would say really, that's the main core idea of functional programming is exposed state and immutable data, right? The rest of it is really nice hardware functions, all this stuff and we call it functional programming, because we to think of it as the thing doing the actions on it, but really at its core, it's about the immutability.

DI: Great

DI：Elixirの方に少し戻しましょう。ブラウザ製品に非常に多いという話をしましたね。多分その実装にElixirは使われてません。関数型プログラミングのスタイルが、エッジアプリのスタイルに影響を及ぼしているかに興味をそそられます

BZ：はい、合ってます。私達はブラウザにとても注力していますし、少なくとも、これまではそうしてきましたが、ブラウザで無ければ解決できないということも無いですね。そう、エッジPoP（訳注：Point Of Presence…配信拠点）にも、クラウドにも応用できますね。これを実行すれば、より少ないコストで済むのですが、そのバックボーンは、全てElixirが得意とする分散システムです。その考えを推奨していると言ってもいい位ですね。実際のモデルとしては、ローカルで処理するのと、リモートで処理するのでは、同じではないですが、かなり似ていますよね？

Elixirエコシステムには、多くの人がいるので、言語やツールそのものだけでなく、実際にプロジェクトに取り組んでいる人達もこれらに興味を持っていますね。CRDT（訳注：Conflict free Replicated Data Type…コンフリクトしない複製可能データ型）や Broadway（訳注：Elixirでデータ処理パイプラインを効率化するライブラリ）をプロジェクトとして物事を進めている人はたくさんいます。実際、高並列を扱ったり、マシン間でデータを移動させたりは、まさに関数型プログラミングで遊んでいる空間と同じなのですが、これは大きな助けになっていて、それは何かをするとき、中央のリソースを持つことができないからです。でも、それがボトルネックになるんですね。分散システムでは、それがボトルネックになります。

オブジェクト指向プログラミングの大きな欠点の1つは、状態をインタフェースの後ろに隠してしまい、空間に閉じ込めてしまうことですね。あるアドレスのあるマシンに移動して、それを探さなければなりません。関数型プログラミングでは、状態を公開して、それを移動させます。たとえば GenServer（訳注：Elixirで状態を保持するフレームワーク）は、現在の状態を更新して、新しい状態を返すことを常に公開していますよね？対象を受け渡すのです。そうですね、ここに アクター（訳注：メッセージをやり取りするプロセスのこと）がいて、アクターはメッセージを発し、それで状態を管理しますが、メッセージを取り出して、データとして移動させても全く問題が無いのです。

メッセージをコピーして、別の場所にそのメッセージのバージョンを送信し、より多くのメッセージを受信することができるのですが、このモデル全体はとても上手く機能し、特に「要素」や「イミュータブルデータ構造」で考えるときは実に上手く機能します。分散システムを構築する上で、ミュータビリティを組み込むことは非常に難しいのですが、関数型プログラミングの核となる考え方は、公開された「状態」と「イミュータブルのデータ」ですよね？あとはナイスなハードウェア機能によるもので、そういうものを全部ひっくるめて、私達は「関数型プログラミング」と呼んでいますが、それはハードウェアの上でアクションを起こすものとして考えていますが、実はその核心は「イミュータブル」にあるのです

DI：素晴らしい

（訳注：下記URLから上記で説明しているCRDTについての解説が見れます）
https://www.youtube.com/watch?v=ogOEEKWxevo

ElixirConfで発表したネットワーク技術

DI: You gave a talk at ElixirConf is year. Could you tell us a little bit about what that was? What the concepts were? With a few following questions.

BZ: Sure. I gave one of the keynotes at ElixirConf in Austin, which was actually the first time I'd been out of Canada in two years, that was exciting. The talk was called "The Jump to Hyperspace", which is about all the things we've just been talking about. Edge computing, the speed of lights, and how that's a barrier, how that in effect becomes a network partition not just latency. Some of the changes that are already happening with things like Low Earth Orbit satellites, things like Starlink, how that's changing the network and the responses that's the industry moving all the way out to software to take advantage of these changes to the network and changes to some of the newer techniques that we have now.

That means, that we don't have to rely on the same, I really don't have to rely on the same ways of doing things as we've done for the last 30 years, but that we've taken that style, really, as probably as about as far as it can go without having to make some fundamental changes. You said you had some follow on questions that might be a good jumping off point.

AH: I've got one. The full title was "The Jump to Hyperspace Lightspeed, antientropy, and moving past the cloud", did I pronounce antientropy correctly? I actually don't know.

BZ: Antientropy. Yes.

AH: Antientropy. Sure. Could you give a brief layman's terms definition, if you will, for our listeners?

BZ: Sure. Absolutely. I touched on, not all of this, but some of this earlier. Entropy as a concept is the tendency of information to become disordered over time or really any systems become disordered over time. Antientropy is a class of techniques to resist or reverse disorder. Make them more ordered again. The one that we're most familiar with as developers is Git, right? You have your main branch and then you forking off of that or branching off of that, and that is a less ordered state, right? There's more versions of that file now. Then you need to go and merge it back in and that's making it less disorder, we have fewer branches and those are coming back together.

The main technique that uses this, or the most famous one these days is a conflict free replicated data type CRDT, which is essentially doing Git merges on data structures, without needing somebody to intervene. Instead of having a PR and then you have to hope that the Git merge will work. Then you have to manually handle anything, this will just do it for you automatically and get everyone into a consistent state.

So doing updates on say, two databases or two devices, running the same software even could even be different software will keep it simple, running the same software and they're both offline, you're both editing a document and you come back online, and they sync up again, you should get a consistent view of that documents at the end without needing a central server. Antientropy is that merging back and resisting having many different possible views of some data, it's getting it back into one consistent state.

AH: I love Git, as the high level example. Earlier, when you mentioned reference systems and books, I thought also, that is an excellent real world example like makes it paints a very clear picture, which I appreciate.

BZ: Oh, thank you.

AH: You're welcome.

DI：今年はElixirConfで講演をされましたね。その内容を少し教えてください。コンセプトは何だったのでしょう？幾つか質問があります

BZ：もちろんです。オースティンで開催されたElixirConfで基調講演をしたのですが、実は2年ぶりにカナダを離れたので、とても刺激的でした。「The Jump to Hyperspace」というタイトルで、今お話したような内容について登壇しました。エッジコンピューティング、光の速さ、それがどのように障壁となり、遅延だけでなく実質的にネットワークを隔てるのか。Starlinkのような低軌道衛星ですでに起きている変化が、ネットワークをどのように変えており、ネットワークの変化と新技術の変化に対応するために、ネットワーク業界はソフトウェアへと移行しているのが現状です

つまり私達は、同じものに頼らなくていい … 過去30年間と同じやり方に頼る必要は本当に無く、一方で、そのスタイルを恐らく根本的に変えることも無く、できる限り同じやり方を続けるでしょう。あなたは、質問したいことがあると言っていたので、その質問を出発点にしましょうか

https://2021.elixirconf.com/

AH：1つあります。タイトル全体は「The Jump to Hyperspace Lightspeed, antientropy, and moving past the cloud」でしたが、「antientropy（訳注：反エントロピー）」の発音は正しかったでしょうか？実は知らないんです

BZ：Antientropy。合ってますよ

AH：Antientropyですね。では、リスナー向けに分かりやすく説明していただけますか？

BZ：もちろんです。全部ではありませんが、先ほどその一部について触れました。概念としてのエントロピーは、情報が時間と共に無秩序になる傾向、あるいはどんなシステムも時間と共に無秩序になる傾向のことです。反エントロピーとは、無秩序に抵抗する、あるいは無秩序を逆転させるための技術の一種です。より秩序立った状態に戻すのです。開発者として最も馴染みがあるのは、Gitですかね？ mainブランチがあって、そこからフォークしたり、ブランチしたりするわけですが、これは秩序を欠いた状態ですよね？そのファイルには、さらに多くのバージョンが存在します。そして、それをマージして戻す必要があります。そうすると少し無秩序は解消されます。ブランチの数が減って、それらが一緒になって戻ってくるのです

これを使った主なテクニックで、最近最も有名なものはCRDTです。これは基本的に誰かが介入することなく、データ構造上でGitマージを行うものです。プルリクエストを行う代わりに、Gitマージが機能することを期待するようにします。すると、手動で何かを処理しなければならないときでも、自動的に処理し、全員を整合性のある状態にしてくれます

たとえば、2つのDBや2つのデバイスで更新を行う場合、同じソフトウェアでも、異なるソフトウェアでもシンプルにでき、両方とも同じソフトウェアによりオフラインでドキュメント編集している場合、オンラインに戻ってくると、再び同期され、最終的には中央サーバを必要とせずにドキュメントの整合性あるビューが得られるはずです。反エントロピーとは、あるデータに対して多くの異なるビューを持つことに抵抗し、マージし直し、それを1つの整合性のある状態に戻すことです

AH：私はGitが好きなのですが、ハイレベルな例に使われましたね。先ほど参考にしたシステムや書籍の話をされたときにも思ったのですが、実世界での優れた例は非常に分かりやすくイメージできるのでありがたいです

BZ：そうですか、ありがとうございます

AH：どういたしまして

（訳注：下記URLから上記で紹介しているElixirConfの基調講演が見れます）
https://www.youtube.com/watch?v=ogOEEKWxevo

顧客や普通の人への説明と、自分達が重要と思うこと

AH: Do you feel being at a research and development company and being the CTO you have to be able to come up with really good, very clear examples that are non-tech related for potential clients?

BZ: Oh, yeah. Very much. Nevermind the potential clients for just literally anyone, right? My CEO, Boris has a technical background, right? He has a CS degree. He's worked as an engineer and come in on Monday morning, having read a couple papers on the weekend. I was like, okay, how can I put this in normal people terms for anyone else to explain why this is important for us to work on? It's from, everyone from my, mom doesn't know what I do, so I have to explain it to her, all the way up to literally my co-founder. So yeah, absolutely.

AH: Yeah. The meme of like what my parents think I do. What my boss thinks I do. What I really do. Yeah. Absolutely.

BZ: Yeah.

AH：研究開発企業にいてCTOになると、潜在顧客に対し、技術とは関係のない、実にいい感じの明確な例を思い付く必要があると感じますか？

BZ：そうですね。かなり。潜在顧客が何者であるかは気にしませんよね？ CEOのボリスは、技術的なバックグラウンドがあります。彼はコンピュータサイエンスの学位を持っています。彼はエンジニアとして働いていて、週末に論文をいくつか読んで、月曜日の朝に出社してきます。私はこう考えるのです … 「オーケー、これがなぜ私達が取り組むべき重要なことなのか？誰かに説明するには、普通の人の言葉でどう言えばいいのだろう？」と。私の母は、私の仕事を知りませんから、私の共同創設者についてまで、彼女に説明しなければなりません。そう、絶対に。

AH：えぇ。「両親が私がしていると思うこと」というようなミーム。上司が私がしていると思っていること。私が実際にやっていること。うん、全くもって

BZ：えぇ

- Translator's impression : 訳者の感想 -

(English version)

We have seen the true potential of "functional programming" and "immutable data" in the content of this article, haven't we?

It is widely known that the key to successfully constructing a distributed system is to manage the "state" and "immutable data" without incorporating mutability, which is typical of OOP, but a new idea was introduced that if this condition is met, all the processing can be "hardwared".

This is an example of how a different programming paradigm can result in a completely different system architecture and an order of magnitude improvement in performance at the same time.

It's an amazing paradigm shift, right?

I would love to incorporate this into my "Programming Theory" course for college students.

The rest of this column will be published on February 15!